Date: Tue, 10 Jun 1997 20:12:18 -0500 From: Wm Brian McCane <root@bmccane.uit.net> To: Chuck Robey <chuckr@glue.umd.edu> Cc: multimedia@FreeBSD.ORG Subject: Re: Old standards Message-ID: <199706110112.UAA28573@bmccane.uit.net> In-Reply-To: Your message of "Mon, 09 Jun 1997 14:19:28 EDT." <Pine.BSF.3.96.970609141552.323c-100000@Journey2.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, 9 Jun 1997, Wm Brian McCane wrote: > > > ADPCM, at 32K samples/second, and `spoke' the alarm to the train over the > > radio. If anyone knows about ADPCM, it only requires about 4K bytes to do a > > 32K/second audio stream. I was thinking about putting together a program for > > audio over the internet using a software version of ADPCM for real-time > > chatting. An 11K/second stream would need about 1375 bytes per second to > > tranfer, so it should work on a 14.4 modem with bytes to spare for the > > TCP/IP overhead, and ADPCM is fairly compressible by modems which might allow > ADPCM (at least when I last looked at it) wasn't all that good as you say > it is. It's one of the non-lossy algorithms, meaning that it keeps all > the information (or nearly all) in the original stream. It was used for > taking a 64 kbps PCM stream and condensing it down to 32 kbps. It maybe > could do a little better, but only at a much great loss of fidelity. The algorithm used by this chip was a lossy algorithm. It had a single bit of data per sample. The sample would start at say 127, then each 0 bit decreases the value by 1, and each 1 bit increased it by 1. If there are 3 bits in a row which are identical, the algorithm uses a catchup value from that point on, say a value of 3, until the current value crosses over the actual target value. This procedure continues for the entire play back, and `approximates' the input data. There are two problems with this algorithm, one is that it is lossy, however at 32K/second the target value doesn't tend to change more than a couple of bits either way. The second problem is a `hiss' equal to 1/2 the sample rate because it is NOT possible to play silence. Instead it plays back 127,128,127,128,127,128,127,128,127,128,127,128. Actually, now that I think about it, there was a 3rd possible problem. When approximating you could overshoot the size of a byte, and get a POP when the value went from 0 to 255 quickly. brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706110112.UAA28573>