I am getting ’ clicking ’ noises on both my repeaters running on a Raspberry_pi 2 using USB_Radio. SD cards are Sandisk ultra high speed. This audio interruption occurs after they have been running for some time. A reboot will cure it, but it comes back. One uses a DMK URI, the other an RA-42. Dahdi_test results show worst is 99.421% and best is 99.604%. From what I read about DAHDI, this needs to be above 99.8% to work correctly. I’m guessing this is the problem. What can be done to improve the results?
Improvement from Bryan W9CR, was posted on the DVSwitch board.
As you can see there is a improvement. Not a big improvement in this case but there is a difference. We have tested on a few different platforms and all exhibit a improvement. It’s actually easy to build and install the dahdi_dummy module.
As root:
edit /usr/src/asl-dahdi-linux-2.11.1/linux/drivers/dahdi/Kbuild
change:
#obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_DUMMY) += dahdi_dummy.o
to:
obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_DUMMY) += dahdi_dummy.o
save your work.cd to /usr/src/asl-dahdi-linux-2.11.1
run:
make install
Once make completes, test your work:
modprobe dahdi_dummy
You should see:
root@demo:/home/szingman# lsmod | grep dahdi
dahdi_dummy 16384 0
dahdi 229376 1 dahdi_dummy
crc_ccitt 16384 1 dahdiIf you do, the module is built and can be installed.
Now we will load it at boot.
edit /etc/modules
add dahdi_dummy above dahdi
save your work
rebootThis was discovered by Bryan W9CR. He compared the binary for dahdi_dummy with what HAMVOIP calls dahdi_hrtimer. A comparison using strings turns up some glaring similarities and differences. I’ll leave this to the community to decide.
Here are some other tests and results. Note: some eagle eyed users will notice some of these tests were not run on the HP DL360 G5. I do not have ASL installed on that machine yet, only DAHDI:
My results on RPi2 running DAHDI dummy:
root@penguin7:~# dahdi_test -c 100
Opened pseudo dahdi interface, measuring accuracy…
99.985% 99.983% 99.989% 99.989% 99.991% 99.987% 99.990% 99.989%
99.989% 99.987% 99.989% 99.990% 99.990% 99.988% 99.991% 99.987%
99.990% 99.988% 99.989% 99.991% 99.988% 99.991% 99.990% 99.988%
99.990% 99.987% 99.990% 99.989% 99.988% 99.991% 99.987% 99.991%
99.989% 99.987% 99.991% 99.987% 99.990% 99.988% 99.989% 99.991%
99.988% 99.990% 99.989% 99.989% 99.991% 99.988% 99.990% 99.990%
99.988% 99.990% 99.988% 99.989% 99.989% 99.989% 99.990% 99.988%
99.991% 99.988% 99.989% 99.991% 99.991% 99.988% 99.989% 99.989%
99.991% 99.985% 99.990% 99.990% 99.989% 99.990% 99.988% 99.989%
99.989% 99.987% 99.991% 99.988% 99.990% 99.989% 99.988% 99.991%
99.987% 99.988% 99.990% 99.989% 99.991% 99.988% 99.989% 99.990%
99.989% 99.990% 99.988% 99.989% 99.990% 99.988% 99.990% 99.987%
99.989% 99.989%
— Results after 98 passes —
Best: 99.991% – Worst: 99.983% – Average: 99.988972%
Cumulative Accuracy (not per pass): 99.989
Ed W8VT
I’m glad to see that the wheel is finally being reinvented. I first talked about the “dummy” timing driver over 10 years ago, back when everything was still Zaptel based. Using the dahdi_dummy driver will indeed help solve some problems, as has been said several times on the app_rpt-users mailing list, in years past. See this reference for the first time I mentioned this. And, for the inquiring minds, the dahdi_hrtimer driver found in HamVoIP performs similar (but not identical) timing tasks.
http://lists.allstarlink.org/pipermail/app_rpt-users/2009-September/001308.html
73, David KB4FXC
So, I’m wondering why dahdi_dummy was renamed and some of the author strings are removed.
Just wondering.
Steve N4IRS
dahdi_dummy is not dahdi_hrtimer.
Ok, I’ll take your word for it.
I cannot get ASL to work for more than a day, and no one seems to be able to answer me as to why. That is why I am still running the ’ Rat_C1 ’ image from July 2017. Will this method work for that as well. The directories are not the same.
Len, I have similar results for dahdi_test:
— Results after 98 passes —
Best: 99.613% – Worst: 98.443% – Average: 99.365985%
Cumulative Accuracy (not per pass): 99.999
I don’t get clicking, I get bubbly audio. Lots of holes in the audio. Just living with it. And this is true on an ACID install as well as a Pi with whatever is the latest. I get worse audio with Limey-Linux running usbradio. In it I get repeating brief sequences of “holes” in the audio that interferes with the generated PL tone, so PL decoding on it is bad. My impression is that the way Asterisk/Allstar use USB to the CM108/119’s has a flaw. Play a tone from radio-tune and you hear the holes repeating rapidly. Same computer, boot to Windows and play a tone through the same device and the tone is pure. It’s either asterisk as implemented or Linux has an issue here.
With all the Pi’s being used my thinking is that using on board audio system would be a good thing, with the GPIO’s of the Pi for COS, PTT, etc…wish I could code…
GeorgeC
I’m curious of the hardware being used, and what the other processes running.
Pure happenstance, after my first node (VIA CPU) physical USB host controller died, I’ve used Intel processors. I have never experienced any of these audio issues. The ASL machines have one job - ASL. Any non essential task, hardware drivers are removed. Bluetooth drivers have been forcefully removed.
I’ve used both USBradio and simpleUSB. I belive let hardware do hardware work - de/encode CTCSS, RX activity.
Also, While evidently not much understood by many, QoS (HTB) is implemented on the router. VoIP traffic on 4569 or whatever port I’m using get ‘top priority.’
If it not implemented, every other audio related needs to be halted, and get QoS properly implemented at your edge router.
The typical occasional audio flutter is found on ARM processors that lack a physical timer function. Intel chipsets have this. Implementing the dahdi_dummy module mimics the hardware and improves the overall timing. Even using intel chipset and true dahdi hardware the dahdi_dummy module has shown some improvement when running dahdi-test. Typical results using ARM architecture 99.6-99.8 with module inserted are 99.97 - 99.99. I don’t have test results in front of me using Intel.
Thank you
Nathan Hardman
Nhardman1428@gmail.com
···
On Dec 2, 2019, at 9:04 PM, Benjamin via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:
December 3I’m curious of the hardware being used, and what the other processes running.
Pure happenstance, after my first node (VIA CPU) physical USB host controller died, I’ve used Intel processors. I have never experienced any of these audio issues. The ASL machines have one job - ASL. Any non essential task, hardware drivers are removed. Bluetooth drivers have been forcefully removed.
I’ve used both USBradio and simpleUSB. I belive let hardware do hardware work - de/encode CTCSS, RX activity.
Also, While evidently not much understood by many, QoS (HTB) is implemented on the router. VoIP traffic on 4569 or whatever port I’m using get ‘top priority.’
If it not implemented, every other audio related needs to be halted, and get QoS properly implemented at your edge router.
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
OK, struggling a bit, possibly due to my limited Linux knowledge.
In following the above instructions (Raspberry Pi, Raspian, latest ASL release, etc) it appears to install dahdi_dummy. Despite some error messages during the install, it concludes with “DAHDI installed successfully.” It suggests installing the package dahdi-tools (which I don’t know how to do or if i should).
When I run modprobe dahdi_dummy i get nothing back and no error, just a new command line.
I also can’t seem to run the test. When I got to /usr/sbin and type sudo dahdi_test I just get “sudo: dahdi_test: command not found”
Any help appreciated.
Thx. Adrian
Being as you did cd /usr/sbin you are in the same directory as the script. With Linux you have to know a trick to execute a script in the same directory. You have to precede the script with a ./ like so ./dahdi_test. That’s because . (ie dot means here) is not in the path on Linux.
You could also do /usr/sbin/dahdi_test but that’s more typing than necessary.
Normally /usr/sbin is in the path. So you can just type dahdi_test from anywhere except /usr/sbin.
Not that nay of that helps you if dahdi is not loaded. Do lsmod to see if it’s loaded.
1 Like
Thx. I appreciate your helping me learn this. I confirmed the module is listed when I type lsmod. However, when I type ./dahdi_test I get a “permission denied” response. I am logged in as root FYI.
Is it executable?
/usr/sbin# ls -l dahdi_test
-rwxr-xr-x 1 root root 10528 Apr 17 2018 **dahdi_test**
The x’s will be set if so.
If not do chmod +rx dahdi_test
Then try running it.
Perfect! Thx. It worked. I did a ./dahdi_test -c 100 and got an avg of 99.989, worse of 99.914. So things are looking good now. Much appreciated!
1 Like
You have learned a couple of key things about Linux. Pretty cool, eh?
1 Like