Would speex be a valid method for compressing/decompressing audio for live communications? Trying to find something that I can use that would decrease the bandwidth requirements tremendously, and still be able to be performed quick enough for live discussion over the air between two communications devices. I have connected two communications devices via the Ethernet, streaming audio via UDP, and the only latency is the internet service provider and net itself, about 200ms - 750ms depending upon connection. But I want to find something that will give me a much much lower bandwidth requirement than "fully uncompressed audio". I wrote my own quick compressor that cuts the bandwidth in about half, but still, want to see "how low can I go". hence the current interest in speex. Thoughts from anyone? Or am I better off looking at a different technology. Thanks, John
On Aug 3, 2011, at 12:16 PM, John Henry wrote:> Would speex be a valid method for compressing/decompressing audio for > live communications?I believe this is one of the intended uses.> Trying to find something that I can use that would decrease the > bandwidth requirements tremendously, and still be able to be performed > quick enough for live discussion over the air between two > communications devices.Speex will certainly decrease the bandwidth. I'm using it to stream audio over a 3G internet connection and it works quite well. Especially for frames of silence which take only 5 bits for 20 ms of silence. (You can also just not send data, but I didn't bother since sending a UDP packet with just a few bytes for the RTP header and 1 byte of data every 20 ms wasn't too much of an overhead.)> I have connected two communications devices via the Ethernet, > streaming audio via UDP, and the only latency is the internet service > provider and net itself, about 200ms - 750ms depending upon > connection. But I want to find something that will give me a much much > lower bandwidth requirement than "fully uncompressed audio". I wrote > my own quick compressor that cuts the bandwidth in about half, but > still, want to see "how low can I go". hence the current interest in > speex.750 ms seems like a pretty big lag for a live conversation, but maybe not so bad. My use didn't require two-way interaction, so I just used a 1 s buffer which worked quite well. Of course, that's on top of whatever the delay from the network was. I suspect that I could have gone quite a bit lower. -- Steve Checkoway
On Wed, Aug 3, 2011 at 16:16, John Henry <jshenry1963 at gmail.com> wrote:> But I want to find something that will give me a much much > lower bandwidth requirement than "fully uncompressed audio". I wrote > my own quick compressor >Hi John, I suggest you subscribe to the "Jitsi" users mailing list as a lot of Jitsi developers hang in there. Jitsi is a SIP VOIP, messaging and video-conferencing client http://www.jitsi.org/ written in Java,with an active development community and they have plenty of experience implementing audio codecs... I?m sure they?ll have plenty of ideas. Here?s the mailing list address (to send mail to, once subscribed) < users at jitsi.java.net> , and here is the web page where you can subscribe to it: http://www.jitsi.org/index.php/Development/MailingLists Hope this helps, and good luck! FC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20110803/35fbb5bf/attachment.htm
2011.08.03. 21:16 keltez?ssel, John Henry ?rta:> Would speex be a valid method for compressing/decompressing audio for > live communications?Audio can mean so many things. Speex is optimized for encoding speech sampled at 8, 16 or 32 kHz (and at least 16 bit strongly recommended). It is a waveform codec, so it can cope with music (e.g. you can expect reasonable quality hold music during calls), but is not designed for it, so for heavy music applications you would be better off looking elsewhere; e.g. Vorbis is quite nice for everyday lossy music compression, or you could try FLAC for lossless, or for something new and low-latency try CELT http://www.celt-codec.org/ from Jean-Marc Valin, the author of Speex.> Trying to find something that I can use that would decrease the > bandwidth requirements tremendously, and still be able to be performed > quick enough for live discussion over the air between two > communications devices.Speex is quite nice for conversations, especially the higher samplerate (16 kHz, 32 kHz) modes - these are rarely provided by other speech codecs (at least until recently) let alone free/open source codecs. It can scale in both bandwidth and CPU requirements (called "complexity") so can fit into a wide range of applications, but if you are thinking low-performance CPU embedded (although that is yet again a relative term), your mileage might vary.