<div dir="ltr">Hello,<br><br>while working on integrating a new codec translator (from/to slin16) into Asterisk I came across a fact which stimulated my curiosity.<br><br>Specifically, I am conducting the first tests on the new translator by observing how it works in recalculating translations, and I see that while translating from slin16 to the new codec the framein function is called with ast_frames which are not what I expected. The anomaly in these frames is that they are reported (by their "samples" member) to consist of 160 samples, but to be (by their "datalen" member) 640 bytes in size. What I expected, given the fact that each sample is 16 bit in size, is that 160 samples would mean a frame "datalen" of 320 bytes.<br>
<br>Exploring this strange phenomenon, I suspect that it is due to a small imprecision in include/asterisk/slin.h, caused by commits related to the issue 15700 (<a href="https://issues.asterisk.org/jira/browse/ASTERISK-15700">https://issues.asterisk.org/jira/browse/ASTERISK-15700</a>). Precisely, it seems to me that in the definition of slin8 and slin16 example frames, the "datalen" member is set to twice the real size of the data in the frame.<br>
The value of the member was correct before the commits in the issue, which IMHO meant simply to change frame data type as uint16_t for ARM compatibility, and consequently adjust the "samples" member to reflect the fact that with uint16_t units, the number of sample in the frame was the same as the total length of the data array. The unintended change is multiplying "datalen" by two, as "sizeof" already gives the currect size of the data in the frame.<br>
<br>I apologize if my explanation is a bit verbose, and would like your confirmation that my guesses are correct and safe in regards to issue 15700 before opening an issue for a correction.<br><br>Best regards<br><br>Gianluca Merlo</div>