I have a new cloud HUB installed 3/9/2025… Every time a node unkeys there is a burst of digital sounding audio. Does not mater what connected node it comes from. sounds the same. Is there audio delay or another way to fix this for RX audio coming into a HUB?
I have heard this intermittently on some connections. Would you open an issue at https://github.com/AllStarLink/app_rpt/issues to document your situation.
As far as I know, no. What you are probably hearing is a traditional analog squelch tail that is being mangled by… I dunno, a frame boundary at the end of the transmission, or something. I’ve heard what you describe, too, but it’s not a new thing with ASL3. It is maybe more apparent, though, because, with more ASL3 nodes coming online that have no compensation for squelch tails, since simpleusb doesn’t currently have rxsquelchdelay, I’m hearing more tails, and thus, the potential for that bouncy boingy sound to happen at the end of transmissions.
I’d be curious, though, to see if my node would exhibit the same behavior on your hub, since I don’t allow squelch tails to exist on transmissions from my radios, though I can easily revert that to make it happen on demand.
It sounds like a rubber band being played as a guitar string.
1 Like
Yep. Interestingly, this only seems to happen with ASL3 sending nodes. Older ASL and HamVoIP, if it breaks at the end of a transmission like that, especially with no rxsquelchdelay, does so a little differently. Instead of a rubber band, you get a tiny little drop-out in the audio.
You can even hear this on a radio-less node with a particularly clicky microphone PTT switch if there is no delay.
So, something must be different about how it’s doing frames, or something.
I’m not sure what the relationship is between this problem and hub nodes. Since I have both ASL3 and HamVoIP nodes available, I’ll have to do some experiments. I think it only happens with simpleusb, not usbradio, but I need to verify that.
1 Like
We’ve been hearing that sound since we added an early ASL3 beta hub to our network; I know the developers are aware of the problem but you peaked my interest when you mentioned a mangled analog squelch tail; The majority of our users are on commercial radios with reverse burst fully in use, so I’m gonna do some experiments myself… maybe whip out the Yaesu…
EDIT: Further testing with a Yaesu VX7-R and a Moto APX8000 both produce the noise, so that tells me reverse burst isn’t the instigator…
Adding that we’ve experienced this also since upgrading the receiving node to ASL3… now that we’ve upgraded the sending node to ASL3 the digital burst still exists…so it doesn’t seem to be an issue between versions
We have a couple of GitHub issues on the audio burst / rubber band twang problem. We “think” we know why this is happening and are testing out a potential fix.