[Home]

Summary:ASTERISK-16633: [patch] downsampling slinear16 to slinear (or ulaw or alaw or g729) results in truncation
Reporter:Paul Albrecht (palbrecht)Labels:
Date Opened:2010-08-31 13:33:19Date Closed:2017-12-14 10:25:21.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Codecs/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) test_translate.c
Description:When I translate from AST_FORMAT_SLINEAR16 to AST_FORMAT_SLINEAR the output frame is truncated, specifically, instead of 160 samples I get 137 samples. The result is the same for ulaw and alaw. For g729, the output is truncated to 80 samples.

****** ADDITIONAL INFORMATION ******

Here's how I initialize the frame I use for translation:

static struct ast_frame f;
static unsigned char data[AST_FRIENDLY_OFFSET + 640];

f.data.ptr = (void *)(data + AST_FRIENDLY_OFFSET);

f.frametype = AST_FRAME_VOICE;
f.subclass = AST_FORMAT_SLINEAR16;
f.samples = 320;
f.offset = AST_FRIENDLY_OFFSET;
f.datalen = 640;

Here's how I translate the frame:

trans = ast_translator_build_path(AST_FORMAT_SLINEAR,AST_FORMAT_SLINEAR16);
out = ast_translate(trans,f,0)

Here's how I log the result:

ast_log( LOG_NOTICE, "my output frame: subclass %d, samples %d, offset %d, datalen %d\n", out->subclass, out->samples, out->offset,out->datalen) ;
Comments:By: Leif Madsen (lmadsen) 2010-08-31 13:48:45

Here is the original thread:  http://lists.digium.com/pipermail/asterisk-dev/2010-August/045945.html
By: Russell Bryant (russell) 2010-08-31 14:17:09

I wrote a small unit test module to test this out and was able to reproduce it.  The output frame has 137 samples every time.
By: Russell Bryant (russell) 2010-08-31 14:25:14

Also, just as a note, in my case, I have codec_resample loaded and it's using that as the translation path.  Results may be different if that module is not loaded, and translation goes through codec_g722.
By: Jason Parker (jparker) 2010-08-31 17:43:26

so, I reversed that test, just because, and it's also wrong (it upconverted via g722 first, so I had to remove that).  Perhaps not very useful, but...

slin16>slin is off by 23 samples (160 - 137)
slin>slin16 is off by 56 samples (320 - 264)

obvious note: 56 is not 23 * 2
By: Alexander Traud (traud) 2017-11-27 08:42:40.883-0600

Mhm. Found this issue by browsing. I am not able to reproduce with my Asterisk 13.18. For me, the amount of samples were fine in both directions. Furthermore, nobody watches this issue anymore.

[~russell], is is possible to get a copy of your unit test?
By: Sean Bright (seanbright) 2017-12-14 10:25:21.302-0600

Per [~traud], this is no longer reproducible with the latest Asterisk 13 release.