Date: Fri, 19 Jan 1996 10:01:38 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: 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: <199601190901.KAA19591@labinfo.iet.unipi.it> In-Reply-To: <199601190223.SAA05047@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 18, 96 06:23:29 pm
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. this does not solve the problem. The best thing the output driver can do (assuming it has a correct clock with sufficient resolution) is to eat samples at 8 KHz. BUT: if the sender is claiming 8KHz but in fact uses a different sample rate (because of inaccuraces), this does not fix anything. It is the receiver side that must adapt to what is coming in (within reasonable tolerance). TV sets have always done this way, they adjust their hsync and vsync to whatever is coming in. What the output driver might try to do, _when working with a stream of incoming data_, is to change speed (i.e. add/discard samples) to avoid the input queue exceed soe low/hi water mark. Only correcting the speed is not enough. > At any rate, this is an intellectual exercise for our sound blaster > champions or our OS gurus 8) In the long term it should go in the driver, I agree. In the short term I think the easiest place to fix this is within the application. > > >>> Luigi Rizzo said: > > > > 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. The comparison with TV sets is more appropriate. But yesterday night was late! > > 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?199601190901.KAA19591>