From owner-freebsd-multimedia Thu Jan 18 18:27:16 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA23836 for multimedia-outgoing; Thu, 18 Jan 1996 18:27:16 -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 SAA23830 for ; Thu, 18 Jan 1996 18:27:11 -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 SAA05047; Thu, 18 Jan 1996 18:23:49 -0800 Message-Id: <199601190223.SAA05047@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo 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 In-reply-to: Your message of "Thu, 18 Jan 1996 23:41:33 +0100." <199601182241.XAA18683@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jan 1996 18:23:48 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk 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/ > ====================================================================