[Asterisk-Dev] G.722 and Grandstream

[Steve Kann]

Andrew Lindh wrote:

>>Steve Kann wrote:
>>
>>You do realize that G.722 audio is 16kHz, and there's code all over 
>>asterisk that assumes 8kHz; even if you decode G.722, you still need to 
>>resample to get 8kHz, and to encode to G.722, you'll need to resample to 
>>16kHz. Then there's all the code that assumes that ms = samples/8, etc..
>>    
>>
>
>Yes, and that's not important.....
>
Could be important...

>G.722 is a 64Kbit/sec (for mode 1)
>data stream. So dealing with the raw G.722 is easy because it
>looks just like G.711. So with any raw G.722 it does not matter that
>it's 16Khz audio.
>
Still could matter...

> On the codec conversion side, yes it would need to be
>resampled to mix and match 8Khz/16Khz. Quick and easy for testing is
>to just drop or add data words to match the rate. I was not planning on
>supporting raw 16Khz in asterisk at all, it would always be raw G.722 or
>converted to 8Khz slin audio. Anything that it would be converted to
>(for now) is 8Khz based anyway, so there would be no issue of quality loss.
>  
>

Here's are three examples of where things will go wrong:

chan_iax2.c:
3472 if (voice)
3473 p->nextpred = p->nextpred + f->samples / 8;

more examples:
app.c: totalms += f->samples / 8;
translate.c: path->nextin.tv_sec += (f->samples / 8000);
translate.c: path->nextout.tv_sec += (out->samples / 8000);


And those are just what I found from grep.. I _think_ you might be OK 
IFF, you're just bridging, and not translating, but anytime asterisk 
needs to convert samples to/from ms, it currently assuming 8 samples/ms, 
and there's not yet a mechanism to pass around information to change 
that in an appropriately variable way.

Also, rtp.c, chan_iax2.c, etc, all presently have codec-specific 
knowledge in them (see rtp.c:ast_rtp_raw_write), that really ought to be 
consolidated somewhere, either in the codec modules themselves (i.e. 
codec->get_samples(frame), etc).

>In my quick test I recorded a G.722 audio stream (just from the dialplan
>record function) and I can play it back to the phone (from the dialplan).
>When I use an external G.722 audio encoder/decoder I don't get valid audio
>from the conversion. So my big issue is I don't have G.722 codec code and
>information that matches the G.722 on the BT-100 phone....
>  
>
That certainly seems like an important issue for you as well :)

-SteveK



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050321/38e5cc08/attachment.htm