Re: Secure voice software issues
First, there has seemed to be general agreement in our earlier discussions of this concept that the hard part is compressing the voice to the point where it can go over commonly-available modems. The government-standard CELP algorithm is too slow for general-purpose home computers. You need an algorithm that can operate in real time and compress intelligibly down to about 13K bits per second.
I downloaded a copy of the GSM 06.10 software (gsm-1.0) from some machine at Technische Universitat Berlin, tub.cs.tu-berlin.de, which does a 13.3 kb/s voice coding, and has conversion for Sun, linear, mu-law, and A-law. (Jutta Degener and Carsten Bormann, Copyright 1992.) It runs in two different modes - a strictly-follow-the-standards mode and a cheat-a-little-using-floating-point mode. In standard mode, piping the compressor into the decompressor ran epsilon faster than real time on a Sparcstation 2, and epsilon slower on a Sun ELC. Cheating mode took about 2/3 as long as standard mode. Looked like it was fairly portable. I compiled it with GCC. One of the readmes says that compression and decompression run faster than realtime on Sparcs, but I assume that means doing just one at a time, not both simultaneously. As is typical, the decompression is about twice as fast as the compression. I assume it won't be quite fast enough on a 486 box, but a "Version 1.0" of anything can often be made faster; I haven't looked at the algorithm to see how much optimizing can be done, but the code's cleanly written and has a bunch of medium-sized tables and unrolled loops suggesting they've at least done some work on speed. Both of these were on samples that were a little fancier than /dev/tty voice; one was /usr/demo/SOUND/sounds/sample.au, and one was the 106.au "It's 106 miles to Chicago, we've got a full tank of gas...." Blues Brothers sound-byte from the net. Haven't tried it on other samples yet, and I need to try running it across the net. I also don't have two 14.4kbs external modems to play with on Sparcs, so I haven't been able to verify which V.42/V.42bis/MNP options will let you squeeze out the start/stop bits to let you fit 13.3 kbps of data over it, but people tell me it should work ok. Bill Stewart
so I haven't been able to verify which V.42/V.42bis/MNP options will let you squeeze out the start/stop bits to let you fit 13.3 kbps of data over it,
Whenever V.42 error correction (LAPM) is enabled, synchronous HDLC frames are what actually pass over the link. So the start/stop bits are already removed. Unfortunately, the packetizing done by LAPM adds delay we don't want for a real time voice application. And if you turn off LAPM, you return to sending the start/stop bits over the wire. Most V.32 and V.32bis modems provide for direct synchronous operation, which would let us have our cake and eat it too, except that few PCs can speak synchronously to a modem. This may require some extra hardware (sigh). Phil
participants (2)
-
karn@qualcomm.com
-
wcs@anchor.ho.att.com