wwmm
When switching VT devices permanently switch to the point of looping into itself
EasyEffects Version
6.2.5+124~git20220617.753a863d
What package are you using?
openSUSE
Distribution
Tumbleweed (rolling)
Describe the bug
Normally, PA runs even on a VT terminal which causes it to take devices from DE and back on every VT switch. Unfortunately, sometimes VT switches are necessary such as when DE decides to break su/sudo and any setuid action, so root rights are on available in the non-DE terminal. But this happens in case of any temporary unavailability of a device. So then EE automatically switches to "the next" device which may even have different profile. And it does not go back automatically.
Even worse, its own virtual device gets permanently auto-selected as "default" in PW which creates a useless loop. And stupid DEs like KDE5 do not provide proper PA device selection in tray, so one has to use something like unmaintained "obsolete" pasystray which may even be removed from one's distribution by its fussy maintainers. Which is especially "great" when using separate devices for speakers and permanently attached pro-headphones.
Such switching does not seem to happen when EE is not active, so I suspect that it toggles api.acp.auto-profile/api.acp.auto-port on. Or maybe I did not have this due to forcing all audio on both DACs simultaneously with qjackctl before using EE. Switching DACs/outputs with hardware button or by software muting is easier than changing PA's default device because there is no good PA mixer with switcher in KDE now.
Expected Behavior
It should not allow using its virtual device as default. Ideally, it should not even selectable. And it should switch back to selected device when it returns. In fact, it should be able to handle multiple devices and profiles simultaneously but it may need cooperation from wireplumber.
Debug Log
No response
Additional Information
No response
It should not allow using its virtual device as default. Ideally, it should not even selectable.
I am not sure this can be done. PipeWire would have to provide some kind of flag where we would say we do not want our virtual devices to be selected as default. As things are right now any audio manager can set them as default and there is nothing I can do to avoid this.
But besides the lack of such a functionality in the server there are some users that need to set our devices as default even if this is not the way EasyEffects(and PulseEffects) is designed to be used. Fortunately it is not common but some app developers insist in setting a Pulseaudio flag that asks the audio server to not allow their streams to be moved anywhere. The application uses only the default device. In these situations the only option the user has is setting our device as default.
This situation is so ridiculous PipeWire had to put Firefox in a list of applications that have this request ignored. I even asked Firefox developers about the reasons why they were doing this but there was no answer... I wish PipeWire would just ignore this flag for all applications. Maybe they do this now. I haven't looked at this in a long time.
And it should switch back to selected device when it returns.
I think I did not understand which device you are thinking about. The 'correct default device"? It should go back to it if PipeWire is broadcasting the change in default device.
So then EE automatically switches to "the next" device which may even have different profile.
Assuming you did not force EasyEffects to pick a custom device (what can be done in our PipeWire tab) it will follow what PipeWire is broadcasting as default. IF it did not come back to the one it should be it may be because PipeWire did not broadcast a new default device event.
I opened https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/296, I agree a new property in wireplumber/pipewire would help.
It should not allow using its virtual device as default. Ideally, it should not even selectable.
I am not sure this can be done. PipeWire would have to provide some kind of flag where we would say we do not want our virtual devices to be selected as default. As things are right now any audio manager can set them as default and there is nothing I can do to avoid this.
I think there are some media.class types for sink/source that do not show up as a selectable device in PA protocol while still being routable in JACK/PW, not sure about possibility of PW routing into them regardless.
In contrast to that, with idea from #1586 it would be preferable to always use visible EE sink/source if it takes over routing. But only in that case.
This situation is so ridiculous PipeWire had to put Firefox in a list of applications that have this request ignored. I even asked Firefox developers about the reasons why they were doing this but there was no answer... I wish PipeWire would just ignore this flag for all applications. Maybe they do this now. I haven't looked at this in a long time.
Firefox/libcubeb is all kinds of broken and unmaintained, there is not much forethought going into Mozilla's decisions >_< Technically, it's hardcoded 75ms latency is in violation of good practices too, as is its hardcoded API selection (which is their "workaround" for avoiding unmaintained and broken cubeb's JACK and raw ALSA backends). And don't get me started on their vsync "implementation" in the year 2022…
And it should switch back to selected device when it returns.
I think I did not understand which device you are thinking about. The 'correct default device"? It should go back to it if PipeWire is broadcasting the change in default device.
The last one actually used. Specifically, one either manually selected in mixer at runtime or "restored" on launch of either PW or EE with user's DE session if no such selection was made. If it's not available when, at least, some real device, maybe anything "known" from "autoload" list.
Either way, it should not select and stay on itself because then it would not be able to route into real hardware. Again, unless routing trick from #1586 is used, so virtual device is used and it cannot disappear to trigger this nonsense.
It a problem because I have to manually switch those devices for using headphones as replugging them into jack connector, like on-board HDA chip creators expected, is bad practice. But switching VT or any other "busy event" throws all real devices out.
Assuming you did not force EasyEffects to pick a custom device (what can be done in our PipeWire tab) it will follow what PipeWire is broadcasting as default. IF it did not come back to the one it should be it may be because PipeWire did not broadcast a new default device event.
I can't pick a single device because I switch them up on occasion. I guess ~~I could decrease the pain by always using headphone DAC by default~~… Nope, that removes switching completely. But that does not address being stuck on EE's own device in a loop. Devices come back with fanfares of KDE's big tray notification but they are not selected back as default. It would be better to disable PW/PA auto-switching of "default" completely.
I think there are some media.class types for sink/source that do not show up as a selectable device in PA protocol while still being routable in JACK/PW, not sure about possibility of PW routing into them regardless.
Sure. There are ways to do that. But then the application device selector won't be able to select our virtual devices. And some people need to do this. So it is not a good idea.
The last one actually used. Specifically, one either manually selected in mixer at runtime or "restored" on launch of either PW or EE with user's DE session if no such selection was made. If it's not available when, at least, some real device, maybe anything "known" from "autoload" list.
We already save the current used device to a variable. If you disable Use Default it should have the last used device. But when EasyEffects is following the system default device this variable will be changed whenever PipeWire broadcasts a new default device.
Either way, it should not select and stay on itself because then it would not be able to route into real hardware.
It doesn't really stay on itself because it ignores its virtual devices when deciding which device it has to use. What is probably happening is that the string with the device name is not being set to something useful when the system default is our own device. This is something I can try to improve.
What is the output of pw-dot when the routing is broken? Its output file can be viewed with xdot.
Depending on what is causing this crash the code in the latest master branch may have fixed it.