On Mon, Mar 21, 2011 at 8:33 PM, Neeraj Chand <<a href="mailto:Neeraj.Chand@ocis.com.au">Neeraj.Chand@ocis.com.au</a>> wrote:<br>> While you're testing, capture iax2 debug info as well as that may point to<br>
> other factors/issues.<br>><br>> Possible fixes:<br>> File conversion:<br>> Yes asterisk can do the conversion<br>> File convert xyz.ulaw xyz.wav <br>> As long as you selected wav format in the initial build. <br>
> Timing module for iax:<br>> Check your modules directory to see which timing sources you have installed.<br>> Res_pthread, res_timerfd and dahdi_dummy would be located there. <br>> Move res_pthread and res_timerfd(if it exists) out of the modules directory<br>
> and restart * to force dahdi dummy.<br><br>Hi again,<br><br>I tried recording a podcast a couple days ago. I recorded in ulaw format, and converted to wav afterwards, as you said. Our session ran over double the length they usually do, over 3 hours. The sync is much better than my first tests, and that is with the jitter buffer enabled - or at least, I believe it is - I saw this output:<br>
<br><span style="font-family: courier new,monospace;">*CLI> iax2 show channels</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">Channel Peer Username ID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format FirstMsg LastMsg</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">IAX2/tayler-129 70.xx.xx.169 tayler 00129/25402 00048/00048 00075ms 0065ms 0119ms ulaw Rx:NEW Rx:ACK</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">IAX2/josh-346 216.xx.xx.2 josh 00346/21060 00138/00175 00088ms 0069ms 0114ms ulaw Rx:NEW Tx:ACK</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">IAX2/dana-1985 66.xx.xx.7 dana 01985/21748 00013/00043 00082ms 0005ms 0079ms ulaw Rx:NEW Tx:ACK</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">3 active IAX channels</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">*CLI> Resyncing the jb. last_delay 67, this delay 2079, threshold 1126, new offset -2079</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">Resyncing the jb. last_delay -189, this delay 1097, threshold 1136, new offset -3176</span><br><br>However, the sync goes out of sync slowly. I recorded both in and out channels for all three participants, and even the pairs don't match up properly. System load was around 0-0.01 the whole time, according to top. Now, for the first hour or so, the sync was fairly OK (only minor adjustment needed), but it drifts after that and I need to adjust more frequently in Audacity.<br>
<br>I am not sure which timing modules I am using. I tried to find the one you mentioned:<br><br>$ sudo find / | grep -i dahdi_dummy | wc -l<br>0<br><br>I figure this is because I compiled Asterisk from source (because I had originally planned to use wideband codec but couldn't find any cross-platform IAX client with wideband support). Is there a way to tell which timer module is in use, or which I compiled in? If I specify in modules.conf which to noload and which to load, would that do the trick (and does that even work when compiled from scratch?). I can always recompile, and I still have my source tree. I also found my old Digium card (it's around 6 years old).<br>
<br>Thanks for your help.<br><br>Dana<br>