Re: [Asterisk-Users] G729 Codec+packet loss concealment
Hi From what I have heard, Asterisk does not allow for iLBC to take advantage of the lost packet concealment. I understand this has something to do with the jitter processing. If lost packet concealment doesnt work with ilbc, I can assume the same applies to other codecs who claim to have this feature. Hopefully this will be fixed sometime soon, especially for us folks with less than ideal IP throughput. Regards Clive On Tue, 03 Aug 2004 10:22:20 +1000 Adam Hart [EMAIL PROTECTED] wrote: Steve Underwood wrote: Adam Hart wrote: Daniel Niasoff wrote: Is G729 more sensitive to packet loss or delays due to its higher compression. If Ive generally got the bandwidth available, am I best sticking to ulaw. G.729 has lost packet concealment, G.711 doesn't. G.711 will sound better otherwise if you can afford the bandwidth. Eh? G.729 has no particular features to allow more effective packet loss concealment. iLBC has, but at the cost of a substantially higher bit rate. In fact G.711 is a little ahead of G.729 in the regard, since packets are completely independant. The smoothing in G.729 means you need the previous packet to decode the current one properly. Regards, Steve I believe you're mistaken - G.729 works similar to iLBC and speex. iLBC works better as the packets are independent but G.729 still has a function for packet loss concealment. prehaps have a look at http://www.speex.org/comparison.html -Adam ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users __ Herbalife Independent Distributor http://www.healthiest.co.za ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] G729 Codec+packet loss concealment
On Tuesday 03 August 2004 02:58, [EMAIL PROTECTED] wrote: From what I have heard, Asterisk does not allow for iLBC to take advantage of the lost packet concealment. I understand this has something to do with the jitter processing. Can you provide a source for that statement? I am not disputing it but I'd like to have it in the archives for one, but also to verify the claim too. Regards, Andrew ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] G729 Codec+packet loss concealment
On Tue, 3 Aug 2004, Andrew Kohlsmith wrote: On Tuesday 03 August 2004 02:58, [EMAIL PROTECTED] wrote: From what I have heard, Asterisk does not allow for iLBC to take advantage of the lost packet concealment. I understand this has something to do with the jitter processing. Can you provide a source for that statement? I am not disputing it but I'd like to have it in the archives for one, but also to verify the claim too. I am the source for that statement. Is that a problem? ;-) My qualification is having worked on the IAX2 jitter buffer, consequently having studied how audio flows from the received frames through the jitter buffer and then via ast_translate() into the codec. To use the iLBC codec's lost packet concealment, you must call the codec every 20msec (or whatever). If you have a new frame, you pass it - and you get that back decoded. If you haven't, you call iLBC_decode anyway, passing mode=0 and get a reconstructed frame back. In Asterisk, bridging is self-clocked by the incoming frames. So unless a frame arrives, nothing happens. Each arriving frame gets pushed through the codec decode function. But if a frame doesn't turn up... well, then... nothing will happen. You can confirm this by examining codecs/codec_ilbc.c where you will see that there is only one call to iLBC_decode(), and that call has a hardcoded mode=1. So Asterisk will never use the iLBC packet loss concealment capability. At the moment, anyway - this can arguably be fixed, but its not a trivial fix. Regards, Steve ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] G729 Codec+packet loss concealment
On Tuesday 03 August 2004 07:18, [EMAIL PROTECTED] wrote: I am the source for that statement. Is that a problem? ;-) Not at all. :-) But I do thank you for taking the time to write a few paragraphs explaining what's going on in the current code. It's certainly something I didn't know before and it really takes out an advantage of using iLBC over something like GSM -- the former has lower bandwidth requirements but the increased processor overhead and lag might be causing another problem I've been seeing. I've switched back to GSM for now to see if the audio quality issues goes away. My qualification is having worked on the IAX2 jitter buffer, consequently having studied how audio flows from the received frames through the jitter buffer and then via ast_translate() into the codec. Hmm... having worked on the IAX2 jitter buffer, can you tell us why trunking and jitter buffers don't get along? When trunking with nufone I get ... interesting... audio if I have a jitter buffer enabled. :-) Hey there, how are you today turns into Heytherehowareyoutoday In Asterisk, bridging is self-clocked by the incoming frames. So unless a frame arrives, nothing happens. Each arriving frame gets pushed through the codec decode function. But if a frame doesn't turn up... well, then... nothing will happen. Aside from easier implementation is there any advantage to having the audio streams self-clocked? -A. ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] G729 Codec+packet loss concealment
Andrew Kohlsmith [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: My qualification is having worked on the IAX2 jitter buffer, consequently having studied how audio flows from the received frames through the jitter buffer and then via ast_translate() into the codec. Hmm... having worked on the IAX2 jitter buffer, can you tell us why trunking and jitter buffers don't get along? When trunking with nufone I get ... interesting... audio if I have a jitter buffer enabled. :-) Getting back to loss concealment for a moment, it seems to me that we could do something like the following: * Every 20ms, call a scheduled function that inserts a silent voice frame into the stream. The frame would be marked as bogus in some way and would be timestamped appropriately. * The jitter buffer should then remove the duplicate voice frames, leaving a constant 20ms stream of either voice data or silence. * The individual codecs should then either spot the frame's bogus marker and deal with it as a dropped frame or, if the codec can't do reconstruction, process the frame as silent audio. I expect that a silent frame would sound much the same as a dropped frame (with no reconstruction) anyway. Does that sound feasible with the current framework? My initial inspection of the SIP/IAX2 code says that it should be, although it'd introduce a fair amount of overhead. -- _/ _/ _/_/_/_/ _/_/ _/_/_/ _/_/ _/_/_/ _/_/ _/_/_/_/_/ _/ K e v i n W a l s h _/ _/_/ _/ _/ _/_/ _/_/[EMAIL PROTECTED] _/ _/ _/_/_/_/ _/_/_/_/ _/_/ ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] G729 Codec+packet loss concealment
If this works, wouldn't it fix the problem using silence supression as well -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Walsh Sent: Tuesday, August 03, 2004 11:22 To: [EMAIL PROTECTED] Subject: RE: [Asterisk-Users] G729 Codec+packet loss concealment Andrew Kohlsmith [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: My qualification is having worked on the IAX2 jitter buffer, consequently having studied how audio flows from the received frames through the jitter buffer and then via ast_translate() into the codec. Hmm... having worked on the IAX2 jitter buffer, can you tell us why trunking and jitter buffers don't get along? When trunking with nufone I get ... interesting... audio if I have a jitter buffer enabled. :-) Getting back to loss concealment for a moment, it seems to me that we could do something like the following: * Every 20ms, call a scheduled function that inserts a silent voice frame into the stream. The frame would be marked as bogus in some way and would be timestamped appropriately. * The jitter buffer should then remove the duplicate voice frames, leaving a constant 20ms stream of either voice data or silence. * The individual codecs should then either spot the frame's bogus marker and deal with it as a dropped frame or, if the codec can't do reconstruction, process the frame as silent audio. I expect that a silent frame would sound much the same as a dropped frame (with no reconstruction) anyway. Does that sound feasible with the current framework? My initial inspection of the SIP/IAX2 code says that it should be, although it'd introduce a fair amount of overhead. -- _/ _/ _/_/_/_/ _/_/ _/_/_/ _/_/ _/_/_/ _/_/ _/_/_/_/_/ _/ K e v i n W a l s h _/ _/_/ _/ _/ _/_/ _/_/[EMAIL PROTECTED] _/ _/ _/_/_/_/ _/_/_/_/ _/_/ ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] G729 Codec+packet loss concealment
On Tue, 3 Aug 2004 05:47:59 -0400 Andrew Kohlsmith [EMAIL PROTECTED] wrote: On Tuesday 03 August 2004 02:58, [EMAIL PROTECTED] wrote: From what I have heard, Asterisk does not allow for iLBC to take advantage of the lost packet concealment. I understand this has something to do with the jitter processing. Can you provide a source for that statement? I am not disputing it but I'd like to have it in the archives for one, but also to verify the claim too. Regards, Andrew Hi Here I am quoting Steve Davies: For IAX2, at least, Asterisk does not use the lost-packet-concealment of any codec. This is because the incoming frames clock Asterisk. For iLBC's lost packet concealment to work, Asterisk would have to start calling the decoder with a NULL at the point when the missing packet should have arrived. Can't say for sure for SIP, but I'd guess that its the same. Steve Regards Clive ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users __ Herbalife Independent Distributor http://www.healthiest.co.za ___ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
