<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thats a bug. AMR-WB is not fixed rate so it should be setting that value to 0. That change will make mod_native_file not load it. Toss me a pull request to fix and I’ll merge it.<div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 23, 2017, at 6:06 PM, ha.ppy.neko <<a href="mailto:ha.ppy.neko@gmail.com" class="">ha.ppy.neko@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Indeed. If mod_amrwb is compiled in paththrough mode it sets encoded_bytes_per_packet to 0 and mod_native_file skips this codec.<br class=""></div>But if mod_amrwb is compiled with transcoding support it sets encoded_bytes_per_packet to SWITCH_AMRWB_OUT_MAX_SIZE constant (61) and mod_native_file registers AMR-WB extension. That was the case for my installation.<br class=""></div><div class=""><br class=""></div><div class="">So my theory was that native playback fails because of incorrect packet size.</div>According to module source AMR-WB has 9 bitrate modes with corresponding voice frame sizes (in bytes):<br class="">0 - 17<br class="">1 - 23<br class="">2 - 32<br class="">3 - 36<br class="">4 - 40<br class="">5 - 46<br class="">6 - 50<br class="">7 - 58<br class="">8 - 60<br class=""><div class=""><div class=""><div class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class="">I recorded test RAW file with FS and record application at max bitrate and resulting file was indeed stream of 62 bytes RTP payloads. 2 bytes AMR-WB header + 60 bytes of voice data. <br class=""></div><div class="">I recompiled mod_amrwb with encoded_bytes_per_packet set to 62 and was able to successfully play RAW file! <br class=""></div><div class="">There was warning "switch_core_file.c:358 File /tmp/recording.AMR-WB sample rate 8000 doesn't match requested rate 16000" but it sounded fine nevertheless.<br class=""></div><div class=""><br class=""></div><div class="">I think this will work with passthrough mode too (change encoded_bytes_per_packet param from 0 to 62), but I don't have time to test it yet.</div><div class=""><br class=""></div><div class=""></div><div class="">Of course I don't know if this change will not break other FS functions, any ideas?</div><div class=""><br class=""></div><div class="">And second problem is that caller may request lower bitrate with frame size 40 for example and RAW file will be sliced incorrectly.</div><div class="">Thats the real deal breaker. Any tips how to make native playback honor negotiated codec and set proper encoded_bytes_per_packet value?<br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">2017-08-23 15:57 GMT+03:00 Michael Jerris <span dir="ltr" class=""><<a href="mailto:mike@jerris.com" target="_blank" class="">mike@jerris.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">That was actually fixed recently. In current master code it won’t register them.<div class=""><div class="gmail-m_-5649738453835469040h5"><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 22, 2017, at 6:50 PM, ha.ppy.neko <<a href="mailto:ha.ppy.neko@gmail.com" target="_blank" class="">ha.ppy.neko@gmail.com</a>> wrote:</div><br class="gmail-m_-5649738453835469040m_2516074307812441061Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I am not sure, but it looks like for given mode AMR and AMR-WB files have fixed frame size.</div><div class="">"The length of the speech frame is implicitly defined by the mode indicated in the FT field": <br class=""></div><div class=""><br class=""></div><div class=""><a href="https://tools.ietf.org/html/rfc4867#page-35" target="_blank" class="">https://tools.ietf.org/html/rf<wbr class="">c4867#page-35</a><br class=""><br class=""></div>Anyway, it is strange that mod_native_file registers AMR and AMR-WB formats if it could not support them.<br class=""><div class=""><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2017-08-23 0:21 GMT+03:00 Anthony Minessale <span dir="ltr" class=""><<a href="mailto:anthony.minessale@gmail.com" target="_blank" class="">anthony.minessale@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">The question was answered by the log line you supplied.<div class=""><br class=""></div><div class=""><span style="font-size:12.8px" class="">-- "cannot play or record native files with variable length data".</span><br class=""></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">VBR codecs are not a predictable size so you cannot make a raw file of it because you don't have any idea how big each packet is.</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div></div></blockquote></div></div></div></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br class=""></div></div></body></html>