Using a Repeater Builder RIM-Lite with an SBC (86x_64) running ASL under a Proxmox VM and I am doing so on several different computers. One thing I do with such a setup is play a .ul audio file (NewsLine, using the localplay command) and it works great. HOWEVER, I’ve been experimenting with some newer, lower power SBC (that run directly on 12v @ around 15-20 watts) and have experienced random audio dropouts of the played back .ul file. I’ve tried both the simpleusb and usbradio drivers with no change, as well as USB 2.0 and 3.0 Ports.
I would think that the problem is in the RIM.
I have seen it before, or at least the complains, and you might find something if you search the forum.
But as I remember it, a call to RIM manufacturer was needed. Something to do with a bad batch of chips in one instance.
Hope that is not your issue, but it does explain why you can do a playback from file without issue but not from input from the rim.
Sorry if I misunderstood.
Well then, Sounds more like a bitrate/codec issue in memory.
Generically, drop-outs are a result of inability to refresh fast enough for memory/cpu etc.
But the question becomes if all seems good, what may be causing excessive use in the system.
Have you tried some other lower bitrate codec ? or even a higher one
As far as I know, you would be using the codec native to the sound file format.
If that were different from the ‘allowed’ codec, I’m sure it is trans-coded to that format. But I guess that is double the work. I do not know how asterisk preforms this feat.
But some experimenting is in order to narrow it down a bit.
I might suggest using files saved in ‘format’ module and not codec.
ie wav, WAV, MP3 etc.
Just make sure the format module is enabled.
If you mean modules.conf loads the .wav drivers, mine is set up to do so however I can’t seem to get my audio files to play the .wav format. What am I missing?
Perhaps what you are missing is…
There are 2 different WAV formats.
.WAV and .wav. The asterisk format module supports .WAV (caps)
Audio PCM uncompressed 16bit 8khz mono(1 channel)
I believe I used ‘sox’ for conversions unless I recorded it with asterisk in the fist place (best when possible).
Monitor ducking is a setting to lower the output on the local node of ‘monitored’ nodes when local traffic is present.
If you do not know about it it is doubtful you are using it.
Well, I have no time to check your syntax. Don’t use this much anymore and don’t remember.
But be sure this module is loaded
load => format_wav_gsm.so ; Microsoft WAV format (Proprietary GSM)
I may have mislead you a bit. It would be compressed…
compressed with GSM codec(would be the capital extension .WAV)
Would you like a method to play AR Newsline back directly from MP3 no conversions ?
I am assuming you are not breaking it apart in segments to allow a break and not worried about timeout.
Although I was working on a good method to do this and auto break apart to avoid timeout, but stopped working on it many years ago. It was just getting to complex for the average user to implement. And I hate writing long howto’s. But the simple and straight forward method is easy to implement.
I don’t play arnews on my nodes, but I use the mp3 player for other stuff. and I just tried it with the ARN service and worked fine for me on a 4 radio-node PC server (2ghz 4GB).
It works great but I’ve been changing out the computers at the various sites to ones that run directly on 12V and use less power. I had no problems with playing Newsline until I started changing computers, hence my starting this thread.
Only one off the path suggestion…
Update the bios/firmware
When I have seen these mini pcs have strange bottlenecks, often it is in usb/interupt handling.
It simply takes them to long to figure out which port needs attention on a interrupt request.
Also, for a test, it might be worthwhile to turn off usb headers not used as they share interrupts often.
So that could cut some delay if that is the issue.
But I would check/update bios/firmware in any case