farhan at phonestack.com
Sat Jun 11 23:42:42 PDT 2005
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
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
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
>>> 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
>>> packets twice (4% effective loss) will be much better than iLBC at 15
>> 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
>>> 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.
More information about the Speex-dev