<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Andrew Lindh wrote:
<blockquote cite="mid200503212142.j2LLghb23290@max.ntplx.net"
type="cite">
<blockquote type="cite">
<pre wrap="">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..
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, and that's not important.....</pre>
</blockquote>
Could be important...<br>
<br>
<blockquote cite="mid200503212142.j2LLghb23290@max.ntplx.net"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
Still could matter...<br>
<br>
<blockquote cite="mid200503212142.j2LLghb23290@max.ntplx.net"
type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
Here's are three examples of where things will go wrong:<br>
<br>
chan_iax2.c:<br>
3472 if (voice)<br>
3473 p->nextpred = p->nextpred + f->samples
/ 8;<br>
<br>
more examples:<br>
app.c: totalms += f->samples / 8;<br>
translate.c: path->nextin.tv_sec += (f->samples /
8000);<br>
translate.c: path->nextout.tv_sec +=
(out->samples / 8000);<br>
<br>
<br>
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.<br>
<br>
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).<br>
<br>
<blockquote cite="mid200503212142.j2LLghb23290@max.ntplx.net"
type="cite">
<pre wrap="">
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....
</pre>
</blockquote>
That certainly seems like an important issue for you as well :)<br>
<br>
-SteveK<br>
<br>
<br>
<br>
</body>
</html>