locked Re: WSJT-X waterfall freezes & stops decoding @ raspberry pi


dpsm64, Georgina,

hanks for the hints!

That gave me the idea to re-check what actual settings i do have in WSJTX regarding audio input/output.

I found that the audio input/output was both set to "pulse", so WSJTX would pass all the output to pulseaudio and pulseaudio should handle all. Same for input.
At least that was my assumption.

Now, what i tried out is following - i've also set both to "plughw:CARD=CODEC,DEV=0". And it worked (at first glance at least).
I could transmit and the waterfall did NOT freezed up.


I'm always checking the input/output level using "pavucontrol", which
is much better then the lxde's built-in sound utility.
(pavucontrol is a pulseaudio's own volume-control utility -
"sudo apt update; sudo apt get -y install pavucontrol")

And, after i started "pavucontrol" and tried to transmit again i got a

"Error in Sound output: An error opening the audio output device has occurred."


So when using "plughw:CARD=CODEC,DEV=0" an EXCLUSIVE access to the hardware is granted to a program that is using it.
In that situation - it was "pavucontrol". And WSJTX did not managed to get access to it.
So, "plughw..." is probably ALSA's direct representation of audio-hardware offered by the kernel.

Now, what i tried one of the next audio-devices which WSJTX *also* see -

* alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo/#0: Audio Adapter (Unitek Y-247A) Analog Stereo
* alsa_input.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-mono/#1: Audio Adapter (Unitek Y-247A) Analog Mono

These names come from PULSEAUDIO, which sit's basically on a top ALSA (which sit's communicates with the kernel).

After i've choosen THEM for input & output, then

* i could transmit
* the waterfall did not freeze up
* both apps, WSJTX and pavucontrol, ran simultaneusly and no one had any troubles

This is, for sure, the most correct behaviour.

The "blocking" behaviour when choosing "plughw:CARD=CODEC,DEV=0" as both devices is reproduceable and is even correct, i assume.
If WSJTX is compiled with alsa-support(which i believe even is the case) it easily can grab a sound-interface directly from ALSA.

My conclusion here is - using the correct interface is the key :-) (facepalm).

However, what the "pulse" device in the list of WSJTX is, is still a big question for me. Maybe WSJTX's own "view" of pulseaudio api?



Join main@WSJTX.groups.io to automatically receive all group messages.