I updated my Pi3 Node with the latest updates on 4/14/2026 and the next day on the morning net with roughly 11 users logged into Echolink everyone on Echolink said everything sounded like they were underwater ..
I quickly restored my last good image from about 3 weeks prior and stuck that online and the problem went away ...
I speculated the new update may have included some new features that required a little better Pi so I created a new Pi4 node with 8GB ram and 32 GB SD card and loaded with the latest ASL3 image ..
To my surprise the next morning during the NET the exact same issue ... The Echolink side users were all hearing everything like it was underwater .. Once again I quickly swapped the new Pi4 setup with the old Pi3 node with an image prior to the latest updated and the issue went away ...
The problem appears to only be the inbound audio TO Echolink .. Echolink output audio is fabulous ... ASL, DVSwitch, WT Mode and the DMR Bridge audio does not appear to be effected ...
Has anyone else experienced this issue with Echolink since the latest update ??
i've been doing some endurance testing of a multi-node raspi3B+ and was getting what i call "choppy audio" after letting it run for some time (duration variable). the host system was being exercised by a busy AllStarLink network (East Coast Reflector) and an Echolink bridge to Kansas City Wide. Prior to setting up and enabling the Echolink module for Asterisk, the audio was never choppy.
i turned to making changes to the way the virtual memory is handled and caused the choppy audio to go away.
if you want to try the same, you need only add a file in /etc/rpi/swap.conf.d - i named it allstarlink.conf and the contents are
I can’t confirm or deny, because I don’t use EchoLink in this way. My system uses a conference server, and there is a constant outbound connection to that from my node, so as many EchoLink connections as the conference can handle can connect, and EchoLink is only ever aware of one connection.
I will say this, though:
This has been a problem in the past. Not sure what the ultimate resolution was, but based on what I heard with my own ears, it sounded like a transcoding problem.
The GSM codec has some watery artifacts at the best of times. What I think might have happened at the time is that GSM was being transcoded to GSM, and with every successive connection, the stack got higher, I.E. the first connection would sound OK, the second would be worse, the third would be even worse than that, etc. and on down the line it went.
I run a large hub with many Echolink users and there's been no issues with Echolink audio for me since the beginning of 3.8 beta. Do you have any errors in logs, issues with CPU performance (e.g. top -d), etc?
I am thirding this issue both repeaters that have echo link access are experiencing the same issue, echolink to the rest of the network sounds found all-star to echo link sounds horrible.
Also so I grabbed the previous asl3 image and loaded it up on an SD card and calibrated all the audio levels and it sounded fine, but the problem is during the first setup at some point a few hours later it automatically updated to the latest asl version might be a good idea to remove this feature from first time setup, incase people need to roll back to a previous version because of some sort of bug.
We just shared a set of ASL3 updates to the "beta" package channel. The asl3-asterisk packages include changes that should help those who were experiencing EchoLink audio issues. You can read more about the changes @ 2026.05.10 - Package Updates - Beta Channel.