Date: Fri, 19 Jan 1996 12:25:01 +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: <199601191125.MAA00392@labinfo.iet.unipi.it> In-Reply-To: <199601191105.DAA00513@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 19, 96 03:04:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I jumped in the discussion because I believe this is a general problem, not only with VAT (which I have never used). 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 ?). I think they do, or at least they ought to. 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. I did not say that this should be done by fine adjustments of the sample frequency at the receiver side. This might be hard or unfeasible. I said that the same effect can be achieved by adding/dropping samples in the stream of data sent to the audio output. > 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 ulaw/alaw to linear is simply a table lookup without loss of precision. Linear to u/alaw is equally a table lookup, although the table is larger and you loose some LSBs (but the quality remains ulaw). The overhead for both conversions is definitely negligible WRT the GSM compression/decompression. 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?199601191125.MAA00392>