From owner-freebsd-multimedia Fri Jan 19 10:49:06 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04035 for multimedia-outgoing; Fri, 19 Jan 1996 10:49:06 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA04030 for ; Fri, 19 Jan 1996 10:49:03 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id KAA00790; Fri, 19 Jan 1996 10:45:58 -0800 Message-Id: <199601191845.KAA00790@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Bill Fenner cc: Luigi Rizzo , 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 In-reply-to: Your message of "Fri, 19 Jan 1996 10:21:33 PST." <96Jan19.102146pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 10:45:57 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk >>> 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