Crackling noise with Pi/ALSA?

[craigerl]

Hi guys, I still don't know what to expect, but maybe you can tell me if this is normal.

I'm using "pat" winlink client in varahf mode and it's communicating with mercury api
just fine, but I'm getting maybe a 5% decode rate and cannot complete a transaction.

https://craiger.org/craiger/mercury-noise.mkv << video/audio, with crackle, is this normal?

It sounds like a sample/bitrate issue I've seen before on some radios and rasperry
Pi, and it's present on the ic7300 and ic705.

I tried forcing 44.1Khz with .asoundrc, but that produced pure noise. is there
a way to have mercury use a sample rate other than 48000Hz?

Loaded configuration from mercury.ini
Audio System: Advanced Linux Sound Architecture (ALSA)
16:53:53.840 [+0.000s] [INF] [main] Async logger initialized (min_level=INFO)
16:53:53.840 [+0.000s] [INF] [main] Initializing I/O from Sound Card
16:53:53.841 [+0.001s] [INF] [radio-io] Initializing radio (type=3085, device=/dev/ttyACM0, hamlib_log_level=0, serial_speed=115200)
16:53:53.841 [+0.001s] [INF] [radio-io] Serial speed overridden to 115200 baud
16:53:53.920 [+0.080s] [INF] [audio-play] I/O playback (default) int32 / 48000Hz / 2ch / 42ms buffer
16:53:54.007 [+0.167s] [INF] [radio-io] Radio control: HAMLIB (model 3085, device /dev/ttyACM0)
16:53:54.007 [+0.167s] [INF] [main] Initializing Modem
16:53:54.007 [+0.167s] [INF] [modem] Created data buffers for ARQ and BROADCAST datalink, tx/rx paths.
16:53:54.009 [+0.169s] [INF] [modem] Initialized persistent FreeDV mode pool (DATAC13/DATAC4/DATAC3/DATAC1), frames per burst: 1
TX test: bytes_per_modem_frame=128, payload_size=126
16:53:54.009 [+0.169s] [INF] [modem] Active FreeDV mode at startup: 12 (DATAC3), verbosity: 0
16:53:54.009 [+0.169s] [INF] [modem] Modem expects sample rate: 8000 Hz
16:53:54.009 [+0.169s] [INF] [modem] Modem payload bytes per frame: 126
16:53:54.009 [+0.169s] [INF] [modem] Split control/data mode switching: ENABLED
16:53:54.022 [+0.182s] [INF] [radio] TX enabled (PTT ON)
16:53:54.048 [+0.208s] [INF] [audio-cap] I/O capture (default) int32 / 48000Hz / 2ch / 42ms buffer
16:53:57.895 [+4.055s] [INF] [radio] TX disabled (PTT OFF)
16:53:57.909 [+4.069s] [INF] [radio] TX enabled (PTT ON)
^X16:54:01.782 [+7.942s] [INF] [radio] TX disabled (PTT OFF)
16:54:01.797 [+7.957s] [INF] [radio] TX enabled (PTT ON)
^C16:54:05.241 [+11.401s] [INF] [main] Termination signal received, shutting down...
16:54:05.248 [+11.408s] [ERR] [audio-cap] ffaudio.stop: snd_pcm_pause: (-5) Input/output error
16:54:05.312 [+11.472s] [INF] [audio-cap] radio_capture_thread exit
16:54:05.440 [+11.600s] [INF] [audio-play] radio_playback_thread exit

[craigerl]

edited audioio.c, to increase buffer, lower sample rate, no change,

18:14:38.042 [+0.012s] [INF] [audio-play] I/O playback (default) int32 / 24000Hz / 2ch / 64ms buffer
18:14:38.045 [+0.016s] [INF] [audio-cap] I/O capture (default) int32 / 24000Hz / 2ch / 64ms buffer

[craigerl]

Same crackling is present on an x86 linux pc using pulseaudio. I can't find an example of what it should sound like anywhere, so just guessing here, please confirm the above video/audio. thanks!

[kc1wzq]

Yeah I notice this too. Most likely the devs have not added a resampler to remove the aliasing. Can you record a video?

[craigerl]

video is in OP,

https://craiger.org/craiger/mercury-noise.mkv

so... alsa issue maybe?

[rafael2k]

That is bad. I'll try to reproduce here, but I did not see it here (I use ALSA 99% of the time).
I'll work on it

[rafael2k]

@craigerl If you can, please try to use ALSA on x86.
On armhf I'll get a psu to use a Pi Zero as a testbed.

[kc1wzq]

video is in OP,

https://craiger.org/craiger/mercury-noise.mkv

so... alsa issue maybe?

Sorry didn't see that. Yes, that is due to mercury having no interpolation. Listen to the audio from your own computer and it might sound aliased, thats what your radio is producing and it makes a ton of unwanted QRM.
73

[craigerl]

I don't know if it helps or not, but I compiled the ffaudio unit tests and they worked well. 8k to 48k conversion?

[craigerl]

observed on pi4, zero2w, armhf build on alsa. and amd64 ubuntu pc on pulse.
both icom705 and icom7300 integrated usb audio

[rafael2k]

Keep samplerate at 48 kHz (if I remember well, this is hardcoded for now).
Can you try just increasing the audio buffer size: #83

[craigerl]

Keep samplerate at 48 kHz (if I remember well, this is hardcoded for now). Can you try just increasing the audio buffer size: #83

I edited the hard-code in audioio.c trying to get this to work, set it to 24K, increased the buffer multiplier to be 60ms, including the 8K-24K multiplier set to 3. no change. It really felt like a usb/buffering issue, i agree.

[craigerl]

switched to crackle branch, popping noise is still present (camera doesn't capture it very well - it's more obvious in person).

https://craiger.org/craiger/mercury-crackle3-85ms.mkv

I was unable to get any sound on x86/alsa, probably because i couldn't fully disable pulse/pipewire. the x86-pulse build has the same crackle.

mercury: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=75decc9123f40fc8c1936a5c36780b59f8f8dca6, for GNU/Linux 3.2.0, not stripped

Linux digipi7 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

[craigerl]

increasing the buffer to 512ms greatly reduces the crackle, and now it's a pop every half a second. increasing to 1000ms makes a pop every second -- we're clearly on to the cause here.

reducing the period from buffer/3 to buffer/8 increases the popping frequency accordingly. so a pop at the start of each period.