[asterisk-dev] downsampling slinear16 to ulaw (or alaw or g729)

[Kevin P. Fleming]

On 08/30/2010 02:29 PM, Paul Albrecht wrote:
> On Mon, 2010-08-30 at 14:15 -0500, Kevin P. Fleming wrote:
>> On 08/30/2010 01:48 PM, Paul Albrecht wrote:
>>
>>> As for AST_FORMAT_SLINEAR16 to AST_FORMAT_SLINEAR translation, I get
>>> truncation, that is, instead of the 160 samples I was expecting I get
>>> 137 samples. I guess I don't know how to interpret these results, if
>>> slinear16/slinear results in truncation that's a bug, right?
>>
>> Yes. That particular transcoding step is just resampling, and it should
>> produce exactly half as many samples as were input (unless an odd number
>> were input, of course).
>>
>>> One more thing to mention, I have translated my silent frame to some
>>> other codecs from wide slinear without truncation. They are gsm, speex,
>>> and g722. Of course g722 is wide so that's not surprising, but I don't
>>> think gsm is wide and it is not truncated.
>>
>> That's somewhat illogical; all paths to 8Khz codecs should go through
>> the same resampling step first, then into the codec. If there are
>> samples being dropped during resampling, it should occur for all of them.
>>
> 
> I don't know what's causing the problem, but the translated gsm and
> speex frames claim 160 samples which is what what I got when I used
> AST_FORMAT_SLINEAR. The g729 was truncated in half, that is, only 80
> samples, which is much worse than ulaw/alaw truncation.

What audio are you feeding in to these translators? It is sampled audio,
all zeroes, all ones, something else?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org