Date: Fri, 19 Jan 1996 03:05:03 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> 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: <199601191105.DAA00513@rah.star-gate.com> In-Reply-To: Your message of "Fri, 19 Jan 1996 10:01:38 %2B0100." <199601190901.KAA19591@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Luigi Rizzo said: > 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. Well, it looks like the easiest thing is to dump vat and just rely on whatever frequency the card runs at. There is no easy way to adjust for frequency oscillations on the receiver side. You would have to have a reference point interlace with the data in order for the receiver to adjust accordingly. Due to the undeterministic behavior of the net it is not sufficient nor desired to depend on the frequency of the incoming packets so in my opinion the reference point would have to be part of the data stream. All fun and games however I think that it would be easier to come up with a different audio tool than to fix vat. The other problem that vat suffers from is that it uses for gsm 8 bit ulaw which is totally bogus. From the gsm's README: GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility with typical UNIX applications, our implementation turns frames of 160 16-bit linear samples into 33-byte frames (1650 Bytes/s). So for our environment it is not desirable to use ulaw because this encurs further unnecessary processing on the system and we may lose precision when expanding 8bit ulaw to 16 bit to be able to feed it to gsm encoding algorithm and I really hate to see what happens on the receiver side. Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601191105.DAA00513>