Hi all, I cover some VoIP issues. I was at VoIP developer conference and asked an embedded manufacturer (we're talking Wi-Fi phones) about supporting Speex in their embedded products. He said that Speex was good but it's too many things to too many people and that he couldn't supported it in his embedded products for the following reasons. * Code size must be extremely small * Data working set must also be extremely small * Use very few MHz of a DSP * Needs packet loss concealment (I believe Speex has this) His recommendation was that because packet overhead alone was in the 24 kbps range, there is nothing wrong with having a 16 KHz wideband stream that uses 24 kbps so long as it meets the above embedded criteria. He said that the VBR support and ultra low bandwidth capability wasn't really useful. What we need is something that would meet the lowest common denominator in hardware yet deliver a wideband stream in less than 24 kbps for the payload. Can someone comment on this? George Ou
> I cover some VoIP issues. I was at VoIP developer conference and asked an > embedded manufacturer (we're talking Wi-Fi phones) about supporting Speex in > their embedded products. He said that Speex was good but it's too many > things to too many people and that he couldn't supported it in his embedded > products for the following reasons.Speex has lots of features but I'm not forcing anyone to use them all.> * Code size must be extremely smallPlease define "extremely small", that's very relative.> * Data working set must also be extremely smallPlease define "data working set" and "extremely small".> * Use very few MHz of a DSPPlease "very few" :-)> * Needs packet loss concealment (I believe Speex has this)Yes, Speex has that.> His recommendation was that because packet overhead alone was in the 24 kbps > range, there is nothing wrong with having a 16 KHz wideband stream that uses > 24 kbps so long as it meets the above embedded criteria. He said that the > VBR support and ultra low bandwidth capability wasn't really useful.Wideband Speex is actually in this range of bit-rate. I usually recommend between 20 and 28 kbps). And I agree that VBR and ultra low bandwidth are useless for that application.> What we need is something that would meet the lowest common denominator in > hardware yet deliver a wideband stream in less than 24 kbps for the payload. > Can someone comment on this?You've pretty much described the main application I had in mind when doing Speex. I really don't see what the problem is. Jean-Marc
Can we get a response from Verisilicon on this? We spoke at the VoIP developer conference and you seemed to indicate that Speex was too difficult for you guys to implement in your embedded products. Mr. Valin would like to know specifically what your criteria is to run on your silicon. He needs to know the following. What is the maximum code size that you can use? What is the maximum data working set you can use? What is the maximum DSP MHz you can spare? I would love to see Speex working in embedded products. Mr. Valin, do you know of any examples of Speex working in embedded gear? George -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, August 17, 2006 10:41 PM To: George Ou Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] RE: Speex-dev Digest, Vol 27, Issue 18> I cover some VoIP issues. I was at VoIP developer conference and > asked an embedded manufacturer (we're talking Wi-Fi phones) about > supporting Speex in their embedded products. He said that Speex was > good but it's too many things to too many people and that he couldn't > supported it in his embedded products for the following reasons.Speex has lots of features but I'm not forcing anyone to use them all.> * Code size must be extremely smallPlease define "extremely small", that's very relative.> * Data working set must also be extremely smallPlease define "data working set" and "extremely small".> * Use very few MHz of a DSPPlease "very few" :-)> * Needs packet loss concealment (I believe Speex has this)Yes, Speex has that.> His recommendation was that because packet overhead alone was in the > 24 kbps range, there is nothing wrong with having a 16 KHz wideband > stream that uses > 24 kbps so long as it meets the above embedded criteria. He said that > the VBR support and ultra low bandwidth capability wasn't really useful.Wideband Speex is actually in this range of bit-rate. I usually recommend between 20 and 28 kbps). And I agree that VBR and ultra low bandwidth are useless for that application.> What we need is something that would meet the lowest common > denominator in hardware yet deliver a wideband stream in less than 24 kbpsfor the payload.> Can someone comment on this?You've pretty much described the main application I had in mind when doing Speex. I really don't see what the problem is. Jean-Marc
George, I have been putting speex into wifi devices for the last two years. If there is one codec that is suited for wifi, it is speex. Your issues: * Code size must be extremely small The Speex compiled codec size is about 60kb, that is less than the smallest sized RAM that you can buy. Speex will even run on the really low powered devices like the Atmel ARMs. * Data working set must also be extremely small The Data working set has little to do with implementation. The current implementation of speex is majorily written by desktop oriented programmers for desktop enviroments. It does a remarkable job of being able to compile itself even on the Symbian devices. However, there is nothing to stop you from writing a small, mono-bit-rate version that will work through a register file of a typical DSP. * Use very few MHz of a DSP You mean, a few Megaflops. It is difficult to find a DSP that does less than a few tens of megaflops. Rather than taking a retrograde step of implementing a lower complexity codec, it makes sense to demand slightly higher performance from the hardware and expect moore's law to take over. * Needs packet loss concealment (I believe Speex has this) If course it does. <quote> His recommendation was that because packet overhead alone was in the 24 kbps range, there is nothing wrong with having a 16 KHz wideband stream that uses 24 kbps so long as it meets the above embedded criteria. He said that the VBR support and ultra low bandwidth capability wasn't really useful. </quote> Speex has no 'packet overhead' those issues are best thrown and Henning Schulzrine and company who designed the RTP. I run speex on a single slot (13 kbps total throughput) on our mobile clients without a problem.Even the 10kpbs wideband codec is quite impressive. As for things that are not 'really useful' leave them out. <quote> What we need is something that would meet the lowest common denominator in hardware yet deliver a wideband stream in less than 24 kbps for the payload. Can someone comment on this? </quote> There is always a complexity/bandwidth trade-off. If you want to crunch speech into a smaller bandwidth, you pay with CPU, that is the fundamental law of dsp (within limits, ofcourse). However, I fail to see why asking for a CPU running at 100MHz is really a problem. They cost about five bucks each. And if you are really looking at lower processing rates, I suggest that you just run G.711 or or GSM 6.10 at 16khz sampling. - farhan George Ou _______________________________________________ Speex-dev mailing list Speex-dev@xiph.org http://lists.xiph.org/mailman/listinfo/speex-dev