I'm not an expert either, but I see people choosing iLBC over speex all the time with asterisk; partly it's because they have more market share in hardphones, and partly it's because of marketing and such. (another reason is that iLBC source is included in asterisk, and speex is only compiled in if you have the speex development stuff on your machine when you compile asterisk [i.e. the speex-devel package]). Some comments below: On Jun 10, 2005, at 12:24 AM, Jean-Marc Valin wrote:> Hi, > > First, you can see a comparison of the codec features at > http://www.speex.org/comparison.html > > As for quality/bitrate, the first thing is that Speex supports a lot > more settings (from 4 to 42 kbps) and does wideband (16 kHz sampling),There's a wideband version of iLBC, but it's not free(as in beer). Skype uses this. (Actually I'm not 100% sure it's called speex, but GIPS makes it, and it's probably closely related).> which iLBC doesn't do. I've only tested iLBC once, but I've found that > Speex has a better quality for the same bit-rate (or lower bit-rate > for > the same quality). This is mainly due to the fact that iLBC is > designed > to encode frames independently (more on this below). Even from their > site, you see that even at 13.3 or 15 kbps (they don't specify which), > they have the same quality as G.729A at 8 kbps.The two different bitrates are just the difference between 30ms and 20ms frame sizes; you use a bit more bps with the 20ms frames.> > Now, their point is that since each frame is independent, the codec is > more robust to packet losses which is good for VoIP. However, in my > opinion (and that of others) is that the price in terms of bit-rate is > too high and you might as well just add redundancy by transmitting > some > packets more than once (as proposed in > http://www.icassp2004.com/Papers/viewpapers.asp?papernum=3280 ). For > instance, if it goes to 20% packet loss, then transmitting 8 kbps > Speex > packets twice (4% effective loss) will be much better than iLBC at 15 > kbps.I think you'd have to look at how Speex (using PLC) compares to iLBC (using PLC) to make an accurate comparison here..> Regarding CPU utilization, I have no idea what iLBC requires. For a > PC I > don't think it actually matters and for embedded systems, then you > have > to pay for a fixed-point iLBC license (Speex includes the fixed- > point in > the same code).since there's so many speex options, it depends on the options you choose. Asterisk presently has poor defaults, and most people link against speex-1.0 code. If you use the latest speex code, and use SSE optimizations, and complexity 2, you get very comparably performance from speex as compared to iLBC. The iLBC reference code is not well optimized, though. -SteveK
Le vendredi 10 juin 2005 ? 21:27 -0400, SteveK a ?crit :> I'm not an expert either, but I see people choosing iLBC over speex > all the time with asterisk; partly it's because they have more > market share in hardphones, and partly it's because of marketing and > such. (another reason is that iLBC source is included in asterisk, > and speex is only compiled in if you have the speex development stuff > on your machine when you compile asterisk [i.e. the speex-devel > package]). Some comments below:Well, it's clear that the marketing department for iLBC is a bit larger than that for Speex ;-) I can't comment on hardphone market share since I have no idea about the iLBC market share (or even that of Speex). However, I think that the (relatively recent) fixed-point should make Speex much more interesting for embedded devices.> There's a wideband version of iLBC, but it's not free(as in beer). > Skype uses this. (Actually I'm not 100% sure it's called speex, but > GIPS makes it, and it's probably closely related)."Not sure it's called Speex"?? I suppose you meant something else?> Even from their > > site, you see that even at 13.3 or 15 kbps (they don't specify which), > > they have the same quality as G.729A at 8 kbps. > > The two different bitrates are just the difference between 30ms and > 20ms frame sizes; you use a bit more bps with the 20ms frames.I'm aware of that, it's just that the quality may not be exactly the same and they don't specify which bit-rate they use when comparing to G.729A. In any way, I find it odd that they compare themselves to a codec that has such a large difference in bit-rate.> > > > Now, their point is that since each frame is independent, the codec is > > more robust to packet losses which is good for VoIP. However, in my > > opinion (and that of others) is that the price in terms of bit-rate is > > too high and you might as well just add redundancy by transmitting > > some > > packets more than once (as proposed in > > http://www.icassp2004.com/Papers/viewpapers.asp?papernum=3280 ). For > > instance, if it goes to 20% packet loss, then transmitting 8 kbps > > Speex > > packets twice (4% effective loss) will be much better than iLBC at 15 > > kbps. > > I think you'd have to look at how Speex (using PLC) compares to iLBC > (using PLC) to make an accurate comparison here..While I haven't compared with Speex, some people http://www.icassp2004.com/Papers/viewpapers.asp?papernum=3280 have found that if you take G.729A and start sending redundant information so that you have the same effective bit-rate as iLBC, then all of a sudden G.729A is *more* robust to packet loss. There's nothing magical about it, there's just so much less loss. This is also despite the fact that G.729A is not optimal for that task (it has a frame size of 20 ms, so they lose several frames in a row when losing a 20 or 30ms packet). I haven't done any formal testing, but I've listened to iLBC samples with 30% packet loss and Speex 8 kbps definitely sounds better than that at 9% loss (which is what you get when transmitting twice).> > Regarding CPU utilization, I have no idea what iLBC requires. For a > > PC I > > don't think it actually matters and for embedded systems, then you > > have > > to pay for a fixed-point iLBC license (Speex includes the fixed- > > point in > > the same code). > > since there's so many speex options, it depends on the options you > choose. Asterisk presently has poor defaults, and most people link > against speex-1.0 code. If you use the latest speex code, and use > SSE optimizations, and complexity 2, you get very comparably > performance from speex as compared to iLBC. The iLBC reference code > is not well optimized, though.Not sure how speed is that relevant on a PC. With the current version, you can encode+decode between 50 and 150 channels (depending on quality/complexity), which is probably enough for most applications. Jean-Marc -- Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> Universit? de Sherbrooke
On Jun 11, 2005, at 4:29 PM, Jean-Marc Valin wrote:> Le vendredi 10 juin 2005 ? 21:27 -0400, SteveK a ?crit : > >> I'm not an expert either, but I see people choosing iLBC over speex >> all the time with asterisk; partly it's because they have more >> market share in hardphones, and partly it's because of marketing and >> such. (another reason is that iLBC source is included in asterisk, >> and speex is only compiled in if you have the speex development stuff >> on your machine when you compile asterisk [i.e. the speex-devel >> package]). Some comments below: >> > > Well, it's clear that the marketing department for iLBC is a bit > larger > than that for Speex ;-) I can't comment on hardphone market share > since > I have no idea about the iLBC market share (or even that of Speex). > However, I think that the (relatively recent) fixed-point should make > Speex much more interesting for embedded devices.It should -- but we'll have to see if it does. iLBC is supported by a handful of hardphones; I haven't heard of any that support speex yet.>> There's a wideband version of iLBC, but it's not free(as in beer). >> Skype uses this. (Actually I'm not 100% sure it's called speex, but >> GIPS makes it, and it's probably closely related). >> > > "Not sure it's called Speex"?? I suppose you meant something else?Oops. That was a thinko -- I meant I'm not sure if they just call it wideband iLBC, or if there's some other name for it.>> [...]>> since there's so many speex options, it depends on the options you >> choose. Asterisk presently has poor defaults, and most people link >> against speex-1.0 code. If you use the latest speex code, and use >> SSE optimizations, and complexity 2, you get very comparably >> performance from speex as compared to iLBC. The iLBC reference code >> is not well optimized, though. >> > > Not sure how speed is that relevant on a PC. With the current version, > you can encode+decode between 50 and 150 channels (depending on > quality/complexity), which is probably enough for most applications.It can never be too fast :). It's totally possible to have 4, 8, or 12 PRI spans terminate on a single box (several quad-span PRI cards) and that's between 92 and 276 channels. Coming soon are T3 cards, which is a few more channels again :) With the right options, speex is competitive -- but the perception (at least in the asterisk community) is that it's very slow. -SteveK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20050611/ac0a1028/attachment.html
i have been working on a voip client that goes head-to-head with skype in technological terms. for this, we used speex wide-band codec. without the denoiser or the pre-processor, i find that speex quality at 16 khz sampling, 16-bit samples (mono) to be clearly superior to anything that skype offers. even though, at the moment, i am not using packet loss compensation, i find that speex is consistenly a better perfomer though the complexity of the code (at a setting of 2) is on the higher side as compared with skype. in a few weeks time, i will make a release of this client for everybody to try it out. at the moment, i am using speex 1.1.8 build on arm and windows. they are also available on our website www.phonestack.com - farhan On Sat, 11 Jun 2005, Jean-Marc Valin wrote:> Le vendredi 10 juin 2005 ? 21:27 -0400, SteveK a ?crit : >> I'm not an expert either, but I see people choosing iLBC over speex >> all the time with asterisk; partly it's because they have more >> market share in hardphones, and partly it's because of marketing and >> such. (another reason is that iLBC source is included in asterisk, >> and speex is only compiled in if you have the speex development stuff >> on your machine when you compile asterisk [i.e. the speex-devel >> package]). Some comments below: > > Well, it's clear that the marketing department for iLBC is a bit larger > than that for Speex ;-) I can't comment on hardphone market share since > I have no idea about the iLBC market share (or even that of Speex). > However, I think that the (relatively recent) fixed-point should make > Speex much more interesting for embedded devices. > >> There's a wideband version of iLBC, but it's not free(as in beer). >> Skype uses this. (Actually I'm not 100% sure it's called speex, but >> GIPS makes it, and it's probably closely related). > > "Not sure it's called Speex"?? I suppose you meant something else? > >> Even from their >>> site, you see that even at 13.3 or 15 kbps (they don't specify which), >>> they have the same quality as G.729A at 8 kbps. >> >> The two different bitrates are just the difference between 30ms and >> 20ms frame sizes; you use a bit more bps with the 20ms frames. > > I'm aware of that, it's just that the quality may not be exactly the > same and they don't specify which bit-rate they use when comparing to > G.729A. In any way, I find it odd that they compare themselves to a > codec that has such a large difference in bit-rate. > >>> >>> Now, their point is that since each frame is independent, the codec is >>> more robust to packet losses which is good for VoIP. However, in my >>> opinion (and that of others) is that the price in terms of bit-rate is >>> too high and you might as well just add redundancy by transmitting >>> some >>> packets more than once (as proposed in >>> http://www.icassp2004.com/Papers/viewpapers.asp?papernum=3280 ). For >>> instance, if it goes to 20% packet loss, then transmitting 8 kbps >>> Speex >>> packets twice (4% effective loss) will be much better than iLBC at 15 >>> kbps. >> >> I think you'd have to look at how Speex (using PLC) compares to iLBC >> (using PLC) to make an accurate comparison here.. > > While I haven't compared with Speex, some people > http://www.icassp2004.com/Papers/viewpapers.asp?papernum=3280 have found > that if you take G.729A and start sending redundant information so that > you have the same effective bit-rate as iLBC, then all of a sudden > G.729A is *more* robust to packet loss. There's nothing magical about > it, there's just so much less loss. This is also despite the fact that > G.729A is not optimal for that task (it has a frame size of 20 ms, so > they lose several frames in a row when losing a 20 or 30ms packet). I > haven't done any formal testing, but I've listened to iLBC samples with > 30% packet loss and Speex 8 kbps definitely sounds better than that at > 9% loss (which is what you get when transmitting twice). > >>> Regarding CPU utilization, I have no idea what iLBC requires. For a >>> PC I >>> don't think it actually matters and for embedded systems, then you >>> have >>> to pay for a fixed-point iLBC license (Speex includes the fixed- >>> point in >>> the same code). >> >> since there's so many speex options, it depends on the options you >> choose. Asterisk presently has poor defaults, and most people link >> against speex-1.0 code. If you use the latest speex code, and use >> SSE optimizations, and complexity 2, you get very comparably >> performance from speex as compared to iLBC. The iLBC reference code >> is not well optimized, though. > > Not sure how speed is that relevant on a PC. With the current version, > you can encode+decode between 50 and 150 channels (depending on > quality/complexity), which is probably enough for most applications. > > Jean-Marc > >