From owner-freebsd-multimedia Tue Jun 10 18:12:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA18618 for multimedia-outgoing; Tue, 10 Jun 1997 18:12:41 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [208.129.189.48]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA18609 for ; Tue, 10 Jun 1997 18:12:31 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.5/8.8.5) with ESMTP id UAA28573; Tue, 10 Jun 1997 20:12:18 -0500 (CDT) Message-Id: <199706110112.UAA28573@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Chuck Robey cc: multimedia@FreeBSD.ORG Subject: Re: Old standards In-reply-to: Your message of "Mon, 09 Jun 1997 14:19:28 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jun 1997 20:12:18 -0500 From: Wm Brian McCane Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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