I haven’t heard this from the RX on the two ASL3 nodes I am currently running with sound fobs attached. One is radioless with an Allscan UCI-120 running simpleusb with no PL filter, and the other has a flat radio attached using usbradio with the appropriate pre/de-emphasis in the usbradio configuration.
I have definitely heard quite a lot of this in the wild from other nodes, though, even on some clear nodes running ASL3. All clear nodes use simpleusb.
When I heard the noise, it immediately reminded me of some sort of time-interval discharge noise.
I can state that every audio interface I've used with ASL has troubles in an electronically-noisy environment. I deployed a new system in late 2024 as an upgrade at our main site. I had it dialed in on the bench - no noise. Take it to the site and BAM! noise. Something in someone else's equipment at our site injects a high-pitch whine on both RX as it's hearable both on the RF repeater and the networked traffic. Drives me batty to the point that I'm probably going to try an RTCM on the repeater.
I am curious what tool people are using to find spikes in various frequencies within an audio stream. That isn't my forte and I'd love to see if I can build a filter for this noise.
You've all gathered some interesting data points, but there are too many variables.
I recommend connecting your USB audio dongles to a laptop and recording the audio directly into a program like Audacity. (These common USB dongles will show up as soundcards on a normal desktop OS). Record silence, record static, record speaking. This test will either blame or exonerate your USB device, the connected equipment (radio), and the RF environment around it.
You can also play back audio files into the adapter and manually key the transmitter, observing the transmitted audio on a known-good receiver or service monitor.
I don't think you'll get anywhere until you run the above tests.
I have three nodes here at the house, one is simple usb, the other two are usb radio, and none exhibit this issue (and I use the nodes daily). But everything about my repeaters and simplex nodes is different from yours, thus the above tests recommended.
Baudline does exactly that and much more
the images are the audio files
I tried a different audio device (RL-20) and took the repeater out of the loop
it still does the raspberries
I will grab some data from that, although that isnt needed as the audio devices are not the issue
then I am going to switch out the computer portion
as i have a x86 box running ASL3 sitting there
I suppose I could try a Pi3b while im at it
So let me get this straight. Without running asterisk, you ran “baudline” and recorded audio from the USB audio device, and this still exhibited the raspberries?
no I was running the same Asterisk with a different sound interface
on the same Pi4 not connected to the repeater
feeding from the genny built into one of my Oscopes
So, I think the best test is to use your same audio interface, same hardware, same radios, and to disconnect the Pi and not use asterisk, and acquire audio from the audio interface using a normal computer with software like Audacity. Most, if not all, of these common audio interfaces will work just fine on a desktop computer.
In other words, completely remove any possibility of asterisk processing anything.
The above test will show if the problem is in asterisk or not.
I have grown weary of this project
2 different interfaces
2 different computers (Pi4 and x86)
same results
I cant convince the interfaces to behave like a normal sound card
I have seen it occur even when setting up a node on the workbench. I can generate a 1KHz tone from a service monitor into a radio receiver, have the SimpleUSB Interface Tune CLI ECHO feature turned on, and then hear it in the playback.
I have tried using USBRadio, and have seen it occur with USBRadio as well.
I have tried various audio devices, such as Masters Communications RL-20M, RL-33M, Repeater-Builder RIM-Lite, RIM-Scom, RIM-RLC, and a few others. Therefore, I do NOT believe it is hardware related.
I have tried using various codecs, from SLIN down to GSM. It seems to occur a little more often with SLIN, but I have been using ULAW for the most part.
All of my system's nodes are running ASL3, and I can hear it occurring on numerous sites at various times. Interestingly enough, I can take one of my sites, disconnect it from my hub node, then connect to a large system of mostly HamVOIP nodes, and never hear it occur, for what that is worth.
Feel free to connect to my system (node 672000) between 10:00am and 12:00pm EST (retiree's daily chat net), and you will hear it occur regularly.
If anyone has any suggestions, I am willing to try them.
It sounds like something peculiar to your configuration or installation.
I've tested MPOW headset, Aursinc hotspot, and Masters RA-30 with simpleusb and usbradio, and do not hear the effect in the original recording.
In addition to cellphones, I've heard this type of artifact before, when a codec loses sync and the timebase/dropout correction fails.
Since nothing has been posted, should we assume that there are no indications of errors in the ASL3 logs or on the asterisk console?
From what I am reading, it is affecting others as well.
As to the installations, all of my installations are professionally done at well managed tower sites. R56 standards followed where possible (another words, nice clean installations, and not your typical slap together ham setups).
The Rasbperrry Pi 5s are encased in full aluminum enclosures (which also act as the passive cooling device. All cabling is shielded. In most installations, the RB RIM Lite is plugged right into a repeater controller such as an RLC or SCOM. I do not suspect any RF or other issues due to the installations. No cellphones are near the equipment.
It is happening at more than one site, and on more than one set of hardware combinations.
I can even duplicate it using a RIM Lite connected directly to a GM300 radio and fed into a service monitor, using shielded RG400 cables at low power. Being it has also occurred using the "E" echo option would lead me to believe this rules out a network issue.
I'm open to other suggestions, but based on the other reports I am seeing, I would have to think it is software related at this point.
I ran HamVoIP on one of the nodes for a brief time, and did not experience any occurrences that I am aware of.
I see you had a test node connected to 67200. There's a traffic net every night for 30-45 mins at 10pm EST. Then things go quiet except for a few night shift guys from time to time. The best time to listen would be during the 10am-12pm old timer net every day. The system is nonstop with traffic at that time.
What I can say, is that there are times where it won't happen at all, then there are times it will happen every few transmissions. For example, I just got on and had a lengthy QSO, and it did not happen once. Yet the other day I must of heard it occur a dozen times. It appears to happen more with some voices than others. Maybe there is some sort of frequency harmonic that is affecting the audio sampling?
If I get a chance over the weekend, I will perform a test using the service monitor and sweep the 0-3000Hz frequency range and see if I can pinpoint a particular area which may trigger it.
As suggested, I can disconnect the USB interface from the Pi and move it to a pc running Audacity, and see if I can duplicate the issue.
Answering my question from looking at the code a bit more. I believe the answer is “yes,” receiver audio goes through the same PLC (and JB) path that the network audio goes through. So, for example, if the audio stream from the USB interface were to underrun for a single frame, the PLC mechanism inside of Asterisk could potentially step in to plug the gap with an interpolated frame.
I’m not saying that’s what’s happening in this case, I’m just sharing one observation from looking at the code. If anyone knows better, please correct me.
Yes, if the "chuffing" sound you are referring to sounds like what is in the audio clip k9wkj has on his blog as mentioned at the top of this topic, then yes, that is what we are dealing with.
I'm not sure which node the test tone was coming from, but it should not have been from a 672xxx node last night. Most likely someone else connected and/or experimenting. I've been guilty of forgetting to disconnect a node in the workshop (due to a startup macro kicking in after restarting ASL to make a change take effect), but not last night!
The chuffing I'm referring to is nothing but bad microphone technique. Some of these guys, you hear as much blowing air as you hear intelligible language.
The closest I heard to the k9wkj clip was every so often a glitch from a dropped packet, maybe 0.1 second audio disruption. I was getting a dropped packet every couple of minutes for the whole time. Every time I heard it, the dropped packet count had incremented. Most of the dropped packets were inaudible.
EDIT: Had to look up whether iax2 show netstats counted packets or frames.
EDIT2: Ya, the tone was definitely someone testing, just happened for a sec.
It’s cool that you can look at counters to see whether there are network drops.
It would be interesting to find out whether the point in the code below is ever happening at one of the sites that is reporting this problem consistently. It doesn’t look like there is a counter.
If I’m reading that right, if the USB receive buffer is shy even a single sample it will quietly return a null frame into Asterisk for that tick period.
IIRC that should result in a mute frame, since that's also how asterisk maintains sync in the audio stream. As long as the codec doesn't choke on null frames, then you really shouldn't hear anything but silence at worst, as long as it's in the audio stream.
BTW, monitoring packet loss is a common method for trouubleshooting frame drop issues.
EDIT: Note that an ast_null_frame is not the same as j_random_frame with a NULL pointer.
