drowe67
[Software Issue] Unwanted change of audio device if freedv-gui is closed with audio to speakers/headphones muted
Platform
Linux
Platform Version
Fedora 41 (pipewire 1.2.7 and wireplumber 0.5.8)
FreeDV Version
freedv-v2.0-dev (and with ms-embed-sioclient)
Steps to Reproduce
If I use pavucontrol to mute the audio sent to the 'FreeDV to Speaker' device then stop the modem and close freedv-gui, at the next startup freedv-gui selects the default audio device (in my case USB Audio speakers).
The still-connected headphone audio device (USB 3.5mm TRRS audio into standard 3.5mm TRS stereo headphones) is ignored which then requires using pavucontrol to reselect the correct audio device (this appears to automatically unmute this device in the pavucontrol playback tab).
Exactly the same setup does not change the audio device if it is not muted in pavucontrol's playback tab, the correct device remains selected.
Expected Behavior
The selected audio device should remain selected while it is still present even if restarting freedv-gui unmutes it.
Actual Behavior
See the reproduction section above.
Additional Comments
No response
Just tried this with pipewire 1.2.7 and wireplumber 0.5.7 and the device configuration seems to stay the same. pavucontrol even continues to have the device muted when freedv-gui starts up again. I'll do a dnf update now and see how that goes.
EDIT: no change after a dnf update and a reboot.
OK, if you let me know what I can do to debug this further I will try to do so, all I can say is that I see nothing in the debug output other than the default device being selected when the normal one is muted.
This could easily be pipewire or wireplumber, I see that it won't be long before pipewire 1.4 is released. I will do a little more experimenting to see if I can give some more information about what happens.
OK, if you let me know what I can do to debug this further I will try to do so, all I can say is that I see nothing in the debug output other than the default device being selected when the normal one is muted.
This could easily be pipewire or wireplumber, I see that it won't be long before pipewire 1.4 is released. I will do a little more experimenting to see if I can give some more information about what happens.
FreeDV should be logging any device changes that pipewire makes. Can you see if it's doing anything like that when this issue happens?
I think I now know what was happening, I had a second USB->3.5mm adaptor plugged in, their names in freedv-gui terms and in the pavucontrol tab were both "USB Audio Analog Stereo" but within pipewire/pulseaudio the 2 devices were named differently.
Somehow, and I don't know where in the system, when I muted the one of these I was using and stopped freedv-gui it was apparently trying to connect to the other device that had a different pipewire/pulseaudio name but the same name in the pavucontrol tab. When this failed it then transferred to using the default audio device which is called "USB AUDIO Analog Stereo" in pavucontrol which is different by means of Audio/AUDIO.
With the second adaptor removed this problem does not happen and freedv-gui selects the correct device after being shutdown and restarted.
Not sure if there is a solution to this, it could be a bug, but I don't know where a resolution should be attempted.
I quickly checked to make sure we weren't doing case-insensitive device name checks and I didn't see anything obvious on the freedv-gui side. Seems like it would be a pipewire issue if anything.
I quickly checked to make sure we weren't doing case-insensitive device name checks and I didn't see anything obvious on the freedv-gui side. Seems like it would be a pipewire issue if anything.
It could be, I will try to do some more checking when I have a mind to.
Further information, something outside of freedv-gui is causing this. I have now noticed that if I mute an output device and then allow the screen saver and eventually the screen blanker and monitor power down then on logging back in to the DE freedv-gui has selected the default audio output device. It appears that my idea of two identically named devices in the pavucontrol playback tab as named by FreeDV is not responsible.
On this basis I think the issue is probably best closed here, I will reopen it if I can't get a resolution via the pipewire/wireplumber route which is probably best left until pipewire 1.4.x lands in Fedora and stabilises.
...
On this basis I think the issue is probably best closed here, I will reopen it if I can't get a resolution via the pipewire/wireplumber route which is probably best left until pipewire 1.4.x lands in Fedora and stabilises.
I am using pipewire 1.4 now and it's all fine here. I just spent about 3 weeks trying to figure out pipewire and it's not easy as most of the documentation is out of date or contradictory.
I had a situation where every time I started a python filter (bandpass for audio to radio) script generated by gnuradio (grc) it auto-connected it's output to the default sound card input and it's input to another unrelated output.
The only solution that I could find was to switch the default sound card to the one I needed while the script was started, and then delete the input link.
To help debugging and scripting during all this I made a few simple (but very useful) pipewire utility scripts which you may find handy. I have put them in github: https://github.com/barjac/pw-utils
It's worth reporting these problems to the pipewire gitlab, the whole sub-system and wireplumber is under heavy development and although each release is an improvement things get broken and then fixed again regularly. I don't know if they have any good regression tests in the code, but it might help.
The documentation is always playing catch-up, sadly this tends to be because of the "the source is the documentation" approach that is all too common when there are too few people who know how it works.