Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Jan 1996 18:23:48 -0800
From:      "Amancio Hasty Jr." <hasty@rah.star-gate.com>
To:        Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc:        james@miller.cs.uwm.edu (Jim Lowe), multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org
Subject:   Re: FreeBSD and VAT 
Message-ID:  <199601190223.SAA05047@rah.star-gate.com>
In-Reply-To: Your message of "Thu, 18 Jan 1996 23:41:33 %2B0100." <199601182241.XAA18683@labinfo.iet.unipi.it> 

next in thread | previous in thread | raw e-mail | index | archive | help

Hi,


We do have a problem with most cards not keeping an accurate frequency
and in fact it can be also a problem for workstations.

You are a little off here. I would rather read the packets at a regular
interval on the driver than attempt to compress or decompress packets.
At any rate, this is an intellectual exercise for our sound blaster
champions or our OS gurus 8) 


I really not sure why vat has to rely on a soundcard to keep its
internal clock -- sounds kludgy to me.

>>> Luigi Rizzo said:
 > > Usually the sound cards are not even close to 8khz.  They are sometimes
 > > off by > 1khz depending on the sound card.  Vat doesn't take this into
 > > consideration.  In fact, Vat uses the sound card for a timer.  It assumes
 > > that the packets are arriving at 8khz and uses this value, no matter what
 > > the record rate actually is, as Vat's internal clock.  The block/packet
 > > size in vat is 160 bytes (or 20ms @ 8khz).
 > 
 > I think there still is a solution, similar to what is used to put
 > the time-of-day clocks in sync on Unix systems. It must be applied
 > to the receive side, of course.
 > 
 > Once you see that packets arrive faster than what the sound card
 > can cope, "compress" packets. If they arrive slower than expected,
 > "expand" them. Theoretically, compression and expansion should be
 > done by resampling the data (expensive) but, given the small
 > differences (1-2 bytes per segment) it probably suffices to
 > duplicate/clip the last bytes of the packet. It helps if you add
 > a 1-packet buffer between the network and the audio device, so you
 > can realize that packets are coming slowly without actually remaining
 > without data.
 > 
 > 	Luigi
 > ====================================================================
 > Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
 > email: luigi@iet.unipi.it       Universita' di Pisa
 > tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
 > fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
 > ====================================================================




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601190223.SAA05047>