Date: Fri, 19 Jan 1996 10:45:57 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: Bill Fenner <fenner@parc.xerox.com> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT Message-ID: <199601191845.KAA00790@rah.star-gate.com> In-Reply-To: Your message of "Fri, 19 Jan 1996 10:21:33 PST." <96Jan19.102146pst.177478@crevenia.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Bill Fenner said:
> In message <199601191125.MAA00392@labinfo.iet.unipi.it>you write:
> >Amancio wrote:
> >> Well, it looks like the easiest thing is to dump vat and just rely
> >> on whatever frequency the card runs at.
>
> This is nonsense; you still need to send data over the network at some
> standard rate.
True but why base your sense of timing on the card?
> >The fact that the net is undeterministic may cause jitter and
> >segment losses. jitter can be compensated somewhat by adding some
> >buffering (and delay) between the net and the audio output. Segment
> >losses can be easily detected if segments carry some sequence number
> >or so (is this the "reference point" you mention before ?).
>
> In fact, vat has a playout buffer that dynamically changes in size based on
> currently observed network jitter.
>
> >Differences in the sample rate between the sender and the receiver will
> >*always* exist to some extent, and are not affected by jitter or
> >segment losses. Even small differences accumulate and will cause clicks
> >in the output, unless the receiver syncronizes with the sender.
>
> In the workstation world, where vat came from, generally audio hardware
> manages to be able to have an exact clock. It's too bad that PC hardware
> can't.
The problem is that we have some cheap or ill design soundcards which
the PC people love to buy as stated before CS4231 based cards
don't have a problem the frequency problem.
> >> The other problem that vat suffers from is that it uses for gsm
> >> 8 bit ulaw which is totally bogus.
>
> Amancio, you really need to tone down your attitude, because you can be real
ly
> insulting sometimes. On most workstation platforms, 8 bit ulaw is what you
> get directly from the audio device -- no translation happens as it does on
> FreeBSD. If 8 bit ulaw is the most efficient thing to use, and the most
> common across platforms, then you use it!
Oh Bill, is not a matter of attitude is matter of conserving CPU cycles for
low end machines which don't have hardware support. vat's interface to
the sound driver should accomodate different sound formats. If I am not
mistaken SGI audio interface is 16bit and not ulaw but it doesn't matter much.
Lets assume that we had a capility of transmitting mpeg am I going to
have to translate my mpeg input format to ulaw to accommodate vat's
current handicap? Is not a matter of attitude is a matter of choice
and cpu utilization. I do expect this year several affordable mpeg codecs
to come to the PC arena . So what I am saying is not a hypothetical case.
At any rate, I didn't mean to upset you.
Take care,
Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601191845.KAA00790>