Re: LPC for speech (fwd)
:Forwarded message: :>From jp12745@coewl.cen.uiuc.edu Fri Dec 10 14:46:07 1993 :From: Jeffrey Wayne Porter <jp12745@coewl.cen.uiuc.edu> :Message-Id: <199312102045.AA16812@eehpx21.cen.uiuc.edu> :Subject: LPC for speech :To: jerry@terminus.dell.com (Jeremy Porter) :Date: Fri, 10 Dec 1993 14:45:49 -0600 (CST) :X-Mailer: ELM [version 2.4 PL22] :Content-Type: text :Content-Length: 948 : :Did you know that using LPC (linear predictive coding) on speech can :near-telephone quality at only 8 k BITs/second? With a signficant :decrease in quality (but still very understandable... probably better :than radio) you can get the rate down to 2kbps. If you don't mind :sounding like a speak&spell, you can go to 600bps or less. : : :Using LPC, you could send real-time voice over the :internet. It would even work (maybe just barely) over a SLIP :connection. According to my professor, LPC can be implemented :in a simple DSP chip, so I figure a 486 ought to be able to :handle it, too. Sound like an interesting (granted maybe not :too useful) project? It would be a way of providing secure :voice communications -- LPC code the speech, encrypt the data :stream, transmit via v.32bis modem, etc. :-- :-------------------------------------------------------------------- :Jeff Porter :jporter@uiuc.edu TA: ECE 290..."ph Jeff Porter" for office hours : : :-- :Jeremy Porter ------------- Systems Engineering -------- :Dell Computer Corp. ------ jerry@terminus.us.dell.com ---- :--- 70 4F BD AE 6D E9 D2 66 48 18 8B E7 64 7F 59 8F --- :Support your Second Amendment rights to encryption technology. : I am working on this very thing. We will be using LPC encoding for compression, IDEA for encryption, and DH key exchange for key handling. We plan to use something better than DH ASAP (something less vulnerable to man in the middle attacks). We plan to use 14.4kbps transmission speed. Lance
I am working on this very thing. We will be using LPC encoding for compression, IDEA for encryption, and DH key exchange for key handling. We plan to use something better than DH ASAP (something less vulnerable to man in the middle attacks). We plan to use 14.4kbps transmission speed. Lance, I'd be interested seeing the protocol that you plan to use. I've given a bit of thought to it, and it appears to me that the protocol should negotiate *everything* up front. This would include data rate, xmit and recv speech coders, as well as crypto algorithm, feed back modes, session keys, etc. I've been thinking also that the protocol should start out in async mode, and then possibly shift to sync mode. It should also be extensible. Eric Blossom
participants (2)
-
Eric Blossom -
loki@nately.UCSD.EDU