Closed ljakob closed 9 years ago
Confirm the same issue.
I successfully tried to turn timing modules. That measure eliminated the noise, but as I understand it could affect the quality of sound.
Same issue here.
Any update ?
If res_timer_timerfd does not perform well enough on your system, you can try installing kmod-dahdi and use res_timer_dahdi (which doesn't depend on any dahdi hardware). This may require to enable build and package the dummy dahdi driver. If you need any help with that, let me know.
See also https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces
@dangowrt, are you sure that AST needs dahdi dummy driver? See https://issues.asterisk.org/jira/browse/DAHLIN-274
You can just try asterisk11-res-timing-dahdi package whether it does work. I cannot test it since I do not have any dongle.
asterisk11-chan-dongle openwrt package has no res_timer module dependency. Are you sure we need one? According to http://wiki.e1550.mobi/doku.php?id=installation => "Note that we don't need Dahdi channel to run chan_dongle, so it can be avoided."
afaik you definitely need a restimer* to run asterisk in general. it can either be timerfd, pthread or dadhi on Linux. strictly speaking, this is not dynamic-link-time dependency of the asterisk, and providing the same function with alternative packages is not well-implemented in the opkg package management; thus, all we could do is adding a asteriskXX-minimal and asteriskXX-full meta-package (similar e.g. to the way strongswan is being packaged) and have them depend on the timer interface we recommend to use. chan-dongle relies on a timer interface for frame scheduling, and the upstream ticket hints that there is some problem when using timerfd. As using pthread is by far not as precise as thus results in additional latency/jitter, I reckon using DAHDI's timing interface could be a good intermediate solution until timerfd works properly with chan-dongle.
We have tried the chan-dongle module and we found out that it requires for the outgoing traffic the same codec, as for the incoming traffic. Sending the data in the same codec resolved issue for me (SLIN-in, SLIN-out)
@jslachta: Can you describe how you configured asterisk? I'll try forcing the codec on an IAX trunk but my example calling an asterisk-internal echo-test from GSM resulted in broken audio as well.
According to the dongle channel info, the only capabilities is already slin:
OpenWrt*CLI> core show channeltype Dongle -- Info about channel driver: Dongle -- Device State: yes Indication: yes Transfer : no Capabilities: (slin) Digit Begin: yes Digit End: yes Send HTML : no Image Support: no Text Support: no
In general you must use only SLIN codec for fully functional playback. Since there might be some synchronization issues on architectures without RTC, I would recommend to use SIP protocol instead of IAX2.
@ljakob Would you be so kind to test this issue on SIP protocol?
On my setup, I only use SIP and the one way audio issue is here.
Just an update to tell you that I was not using the correct DATA port (/dev/ttyUSB0 instead of /dev/ttyUSB2) with the dongle. With the correct DATA port, the one way audio issue is not present anymore (with SIP and no timing source).
Installed fresh version of OpenWRT, the latest versions of packages - the issue is still here. Tried all timing modules with the same result:
[dongle -> network] voice quality is perfect in both cases.
The following timing modules were tried: pthread, dahdi, timerfd.
Probably, it is possible to solve the issue without using the modules. @jslachta , can you please explain how exactly you played with codecs?
OpenWrt_CLI> core show channeltype Dongle -- Info about channel driver: Dongle -- Device State: yes Indication: yes Transfer : no Capabilities: (slin) Digit Begin: yes Digit End: yes Send HTML : no Image Support: no Text Support: no OpenWrt_CLI> core show codecs Disclaimer: this command is for informational purposes only. It does not indicate anything about your configuration.
100001 audio g723 (G.723.1) 100002 audio gsm (GSM) 100003 audio ulaw (G.711 u-law) 100004 audio alaw (G.711 A-law) 100011 audio g726 (G.726 RFC3551) 100006 audio adpcm (ADPCM) 100019 audio slin (16 bit Signed Linear PCM) 100007 audio lpc10 (LPC10) 100008 audio g729 (G.729A) 100009 audio speex (SpeeX) 100016 audio speex16 (SpeeX 16khz) 100010 audio ilbc (iLBC) 100005 audio g726aal2 (G.726 AAL2) 100012 audio g722 (G722) 100021 audio slin16 (16 bit Signed Linear PCM (16kHz)) 300001 image jpeg (JPEG image) 300002 image png (PNG image) 200001 video h261 (H.261 Video) 200002 video h263 (H.263 Video) 200003 video h263p (H.263+ Video) 200004 video h264 (H.264 Video) 200005 video mpeg4 (MPEG4 Video) 400001 text red (T.140 Realtime Text with redundancy) 400002 text t140 (Passthrough T.140 Realtime Text) 100013 audio siren7 (ITU G.722.1 (Siren7, licensed from Polycom)) 100014 audio siren14 (ITU G.722.1 Annex C, (Siren14, licensed from Polycom)) 100017 audio testlaw (G.711 test-law) 100015 audio g719 (ITU G.719) 100028 audio speex32 (SpeeX 32khz) 100020 audio slin12 (16 bit Signed Linear PCM (12kHz)) 100022 audio slin24 (16 bit Signed Linear PCM (24kHz)) 100023 audio slin32 (16 bit Signed Linear PCM (32kHz)) 100024 audio slin44 (16 bit Signed Linear PCM (44kHz)) 100025 audio slin48 (16 bit Signed Linear PCM (48kHz)) 100026 audio slin96 (16 bit Signed Linear PCM (96kHz)) 100027 audio slin192 (16 bit Signed Linear PCM (192kHz))
@andr2k Are you trying that on SIP or IAX2 protocol?
@jslachta , SIP.
Hi, I've solved the problem myself - it was an endianness bug:
Here what gave me the correct clue:
The bug is in the audio handling of timing_write in channel.c, the data sent to the socket is not changed to the correct endianness if a timing device is used.
Here is my patch, it's untested (just one call yet) but it's trivial enough: http://www.hugo.weite-welt.com/asterisk13_chan_dongle_endianess.patch it is against asterisk13 branch in https://github.com/oleg-krv/asterisk-chan-dongle.git but should fit into other asterisk versions nicely
That's good news! I imported your patch in 2b304f867c598368f21caaf23e10ae7684326c71 . Please test if the it fixes the issue.
@dangowrt : Could you push an chan_dongle package for asterisk13 with that patch within the openwrt-repository? I've switched my installation to asterisk13 already.
I suggest anyone with the resources to actually test this on real hardware and with all supported asterisk versions to package chan-dongle for 1.8, 11 and 13 using build variants similar to chan-sccp-b or asterisk-g72x. I'm happy to assist and review. Can someone confirm that the currently build version of chan-dongle for asterisk-11.x now works on big-endian devices like the ar71xx? @andr2k @iamnague @ljakob ?
I will be able to test current build during the next week.
I'd love to test current build version of chan-dongle for asterisk-11 but I'm still running BB 14.07 and I can no longer install trunk packages: I always get the “default_postinst: not found”… If anybody can tell me how to bypass this error ?!
Edit: I manualy extracted the chan_dongle.so from the package but it isn't loading:
[Jun 26 12:32:05] WARNING[22153]: loader.c:439 load_dynamic_module: Error loading module 'chan_dongle.so': File not found [Jun 26 12:32:05] WARNING[22153]: loader.c:452 load_dynamic_module: Module 'chan_dongle.so' did not register itself during load [Jun 26 12:32:05] WARNING[22153]: loader.c:918 load_resource: Module 'chan_dongle.so' could not be loaded.
Asterisk 11.12.0 / ar71xx
Anyone else tested this patch ?
Hi , same problem. I tested the patch and for me nothing has changed. My dongle works on the motherboard USB two side audio . But usb hub gets cutting audio . debugging in Hub i see x times - res_timing_timerfd.c : Expected to acknowledge one ticks but instead got 2
Updated everything to the latest version - cannot install asterisk11 at all.
root@OpenWrt:/etc/config# opkg install asterisk11
Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/generic/packages/telephony/asterisk11_11.18.0-3_ar71xx.ipk.
Collected errors:
* opkg_install_pkg: Failed to verify the signature of /var/opkg-lists/chaos_calmer_telephony.
* opkg_install_cmd: Cannot install package asterisk11.
Any update ? Did someone test this patch?
Hi, I've used the patch over the last month on my box and it works perfectly. Audio gain from my old x86 installation had to be copied but that was expected. There have been at least 100 calls without any problems.
I used my own build of asterisk13 on CC RC2 but that should't make any difference.
Update: I use res_timing_timerfd.so for IAX-timing; "timing test" returns fine
Hi,
I just bought the dongle, so I will be able to test it during the next week.
Jiri Dne 8.9.2015 15:16 napsal uživatel "iamnague" notifications@github.com:
Any update ? Did someone test this patch?
— Reply to this email directly or view it on GitHub https://github.com/openwrt/telephony/issues/7#issuecomment-138556551.
Recreated from: https://dev.openwrt.org/ticket/18672 Problem is on: Barrier Breaker 14.07
Hi,
I've moved my asterisk installation (Debian x64) to my OpenWrt-Box:
All is working fine, but the chan_dongle has a broken audio channel for audio from asterisk to the GSM network, the other direction is fine.
Hardware is:
A simple test is:
Setup chan_dongle with a incoming context like this:
You need some more packages for playback of the standard asterisk gsm audio files.
And call the dongle. Expected would be to hear the welcome message and then enter the echotest. The welcome message is not understandable on the mobile device also the echotest.
My first guess was, that there is a endianess problem (UMTS-stick has little endian, host has big endian) but a quick look into the sourcecode revealed that endianess switching is done on the outgoing channel. The audio sounds like that there is a endianess mixup because calling with a SIP device into the GSM network generates very loud noise on the GSM side while sending silence.
The defect looks like
https://code.google.com/p/asterisk-chan-dongle/issues/detail?id=112
but it's not a codec conversion issue; even sending SLIN-codec from an other box via IAX2 didn't resolve the issue.
Any idea?
Leif