On 08/30/2010 10:53 AM, Paul Albrecht wrote: > On Mon, 2010-08-30 at 10:30 -0500, Kevin P. Fleming wrote: >> On 08/30/2010 10:16 AM, Paul Albrecht wrote: >>> On Mon, 2010-08-30 at 10:02 -0500, Kevin P. Fleming wrote: >>>> On 08/30/2010 09:39 AM, Paul Albrecht wrote: >>>> >>>>> I have a question about asterisk transcoding from wide slinear to ulaw >>>>> (or alaw or g729). Specifically, the result I get when I translate from >>>>> AST_FORMAT_SLINEAR16 to AST_FORMAT_ULAW is truncated, that is, I don't >>>>> get a 160 samples in the output frame. Is this a bug or should I have >>>>> expected the translator to truncate the result? >>>> >>>> How many samples were in the input frame? Is there a smoother involved? >>>> >>> >>> The slinear16 frame contains 320 samples and I'm getting 137 samples of >>> ulaw out which is not what I expected. I was looking for a full 160 >>> samples of ulaw. >>> >>> I don't know if a smoother was involved. Here's how I do the >>> translation: >>> >>> trans = ast_translate_build_path(AST_FORMAT_ULAW,AST_FORMAT_SLINEAR16); >>> out = ast_translate(trans,in,0) >> >> That certainly sounds like a bug then; there's no smoother involved with >> that type of construction. Can you post the contents of the ast_frame >> structure called 'in' (but not the data)? >> > > The translated frame is silent, that is, all the samples are zero so > that's easy. Here's the code for how I set the input frame: > > 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; > > Is this enough or do you want me to write particular fields to the log > file or is there another way to dump the frame?
No, that's enough, and it appears to be correct. I don't see any obvious reason why that would be failing. To debug it further, I'd change it to output AST_FORMAT_SLINEAR, and see if you get 160 samples; if not, you've found the step that is causing the problem, and if so, you've still found it :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kflem...@digium.com Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-security mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-security
