wwmm
Easyeffect doesn't recconect to the "default" device
EasyEffects Version
7.1.4
What package are you using?
Flatpak (Flathub)
Distribution
Ubuntu
Describe the bug
When we have easyeffect running and we switch off and on an usb output device easyeffect doesn't reconnect to the "default" device. Without easyeffect running clients correctly reconnect to the default sink device.
Check
Expected Behavior
No response
Debug Log
Debug Log
Paste your log here
Additional Information
No response
Kill it and restart in debug mode G_MESSAGES_DEBUG=easyeffects flatpak run com.github.wwmm.easyeffects so we can see if it prints messages about the new device.
In the debug log I see the event when the device is turned on again but then we had an error. Here the sequence after I turn off and on the device:
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
(easyeffects:2): easyeffects-DEBUG: 17:07:46.549: application.cpp:132 device alsa_card.usb-<my_device> has changed its output route to: analog-output
(easyeffects:2): easyeffects-DEBUG: 17:07:46.549: application.cpp:152 output autoloading: the target node name does not match the output device name
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
device alsa_card.usb-<my_device> has changed its output route to: analog-output
Does it change to the analog-output route when the usb device is turned on? Based on the output there is no signal about default device changes. I was expecting to see a signal about your onboard soundcard being set as default after you turned off the external usb device. Strange...
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
I definitely do not see these errors here on Arch Linux. If they are the cause of the problem I do not know. But it is not normal to have them. What PipeWire version is being reported by EasyEffects logs?
But it is not normal to have them. What PipeWire version is being reported by EasyEffects logs?
At least not in the native package. I am not sure if in the Flatpak package this is a normal.
The log was just after the device switched on.
Here the sequence usb device on and play e.g. spotify client and then stop:
(easyeffects:2): easyeffects-DEBUG: 18:01:33.546: stream_output_effects.cpp:150 At least one app linked to our device wants to play. Linking our filters.
(easyeffects:2): easyeffects-DEBUG: 18:01:33.609: plugin_base.cpp:370 soe: equalizer successfully connected to PipeWire graph
(easyeffects:2): easyeffects-DEBUG: 18:01:33.610: pipe_manager.cpp:1259 easyeffects_sink port 57 is connected to ee_soe_equalizer port 149
(easyeffects:2): easyeffects-DEBUG: 18:01:33.615: pipe_manager.cpp:1259 easyeffects_sink port 111 is connected to ee_soe_equalizer port 104
(easyeffects:2): easyeffects-DEBUG: 18:01:33.631: app_info.cpp:144 cannot lookup application icon com.spotify.Client in /usr/share/pixmaps
(easyeffects:2): easyeffects-DEBUG: 18:01:33.632: app_info.cpp:144 cannot lookup application icon com.spotify.Client in /usr/local/share/pixmaps
(easyeffects:2): easyeffects-DEBUG: 18:01:33.654: output_level.cpp:37 soe: output_level: PipeWire blocksize: 2048
(easyeffects:2): easyeffects-DEBUG: 18:01:33.654: output_level.cpp:38 soe: output_level: PipeWire sampling rate: 48000
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
(easyeffects:2): easyeffects-DEBUG: 18:01:34.598: app_info.cpp:144 cannot lookup application icon com.spotify.Client in /usr/share/pixmaps
(easyeffects:2): easyeffects-DEBUG: 18:01:34.598: app_info.cpp:144 cannot lookup application icon com.spotify.Client in /usr/local/share/pixmaps
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
(easyeffects:2): easyeffects-DEBUG: 18:01:44.419: stream_output_effects.cpp:162 No app linked to our device wants to play. Unlinking our filters.
(easyeffects:2): easyeffects-DEBUG: 18:01:44.419: stream_output_effects.cpp:328 disconnecting the equalizer filter from PipeWire
(easyeffects:2): easyeffects-DEBUG: 18:01:44.425: pipe_manager.cpp:213 163 ee_soe_equalizer has been removed
(easyeffects:2): easyeffects-DEBUG: 17:59:03.499: pipe_manager.cpp:213 Audio/Sink 71 alsa_output.usb-<my device> has been removed
(easyeffects:2): easyeffects-DEBUG: 17:59:03.512: plugin_base.cpp:370 soe: equalizer successfully connected to PipeWire graph
(easyeffects:2): easyeffects-DEBUG: 17:59:03.517: pipe_manager.cpp:1259 easyeffects_sink port 122 is connected to ee_soe_equalizer port 157
(easyeffects:2): easyeffects-DEBUG: 17:59:03.519: pipe_manager.cpp:1259 easyeffects_sink port 163 is connected to ee_soe_equalizer port 51
(easyeffects:2): easyeffects-DEBUG: 17:59:03.552: node_info_holder.cpp:98 71, alsa_output.usb-<mydevice> finalized
(easyeffects:2): easyeffects-DEBUG: 17:59:13.425: stream_output_effects.cpp:162 No app linked to our device wants to play. Unlinking our filters.
(easyeffects:2): easyeffects-DEBUG: 17:59:13.425: stream_output_effects.cpp:328 disconnecting the equalizer filter from PipeWire
(easyeffects:2): easyeffects-DEBUG: 17:59:13.429: pipe_manager.cpp:213 71 ee_soe_equalizer has been removed
Device off
(easyeffects:2): easyeffects-DEBUG: 18:04:06.607: pipe_manager.cpp:213 Audio/Sink 84 alsa_output.usb-<mydevice> has been removed
(easyeffects:2): easyeffects-DEBUG: 18:04:06.630: plugin_base.cpp:370 soe: equalizer successfully connected to PipeWire graph
(easyeffects:2): easyeffects-DEBUG: 18:04:06.633: pipe_manager.cpp:1259 easyeffects_sink port 57 is connected to ee_soe_equalizer port 130
(easyeffects:2): easyeffects-DEBUG: 18:04:06.638: pipe_manager.cpp:1259 easyeffects_sink port 111 is connected to ee_soe_equalizer port 99
(easyeffects:2): easyeffects-DEBUG: 18:04:06.712: node_info_holder.cpp:98 84, alsa_output.usb-<mydevice> finalized
(easyeffects:2): easyeffects-DEBUG: 18:04:17.425: stream_output_effects.cpp:162 No app linked to our device wants to play. Unlinking our filters.
(easyeffects:2): easyeffects-DEBUG: 18:04:17.425: stream_output_effects.cpp:328 disconnecting the equalizer filter from PipeWire
(easyeffects:2): easyeffects-DEBUG: 18:04:17.430: pipe_manager.cpp:213 84 ee_soe_equalizer has been removed
Device on
easyeffects:2): easyeffects-DEBUG: 18:06:17.866: pipe_manager.cpp:1219 Audio/Sink 97 alsa_output.usb-<mydevice> with serial 2789 has been added
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
(easyeffects:2): easyeffects-DEBUG: 18:06:17.878: pipe_manager.cpp:213 Audio/Sink 97 alsa_output.usb-<mydevice> has been removed
(easyeffects:2): easyeffects-DEBUG: 18:06:17.878: pipe_manager.cpp:1219 Audio/Sink 97 alsa_output.usb-<mydevice> with serial 2790 has been added
(easyeffects:2): easyeffects-DEBUG: 18:06:17.879: node_info_holder.cpp:98 97, alsa_output.usb-<mydevice> finalized
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
(easyeffects:2): easyeffects-DEBUG: 18:06:17.888: application.cpp:132 device alsa_card.usb-<mydevice> has changed its output route to: analog-output
(easyeffects:2): easyeffects-DEBUG: 18:06:17.888: application.cpp:152 output autoloading: the target node name does not match the output device name
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
'spa_pod_is_array(pod)' failed at /app/include/spa-0.2/spa/pod/iter.h:319 spa_pod_get_array()
Ok. So EasyEffects sees that your usb device came back. In the beginning of its logs it shows which devices PipeWire reports as default. What is there?
Also try to do the following test. Go to the pipewire tab in EasyEffects and set your usb device as EasyEffects output instead of the automatic default device selection. Does the audio comes back when the usb device comes back?
. Go to the pipewire tab in EasyEffects and set your usb device as EasyEffects output instead of the automatic default device selection. Does the audio comes back when the usb device comes back?
I've already tested this. When the usb device power off it switch to the "fallback" internal device. When it is power on it stay on the "fallback device" also if I have specifically selected the usb one before power off.
Of course If I manually switch there after the usb device comes back it is going to work again.
Could this be related to https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/384?
But it seems it was fixed a long time ago.
As I see in the previous pasted logs:
(easyeffects:2): easyeffects-DEBUG: 18:06:17.888: application.cpp:152 output autoloading: the target node name does not match the output device name
As I see in the previous pasted logs: (easyeffects:2): easyeffects-DEBUG: 18:06:17.888: application.cpp:152 output autoloading: the target >node name does not match the output device name
This error is only relevant for the preset autoloading. But besides the fact that it is not always a reason for concerning the issue you are facing can not be caused by a broken autoloading. The most that a broken autoloading can do is not loading your preset automatically. You would still have audio.
I've already tested this. When the usb device power off it switch to the "fallback" internal device. When it is >power on it stay on the "fallback device" also if I have specifically selected the usb one before power off.
Of course If I manually switch there after the usb device comes back it is going to work again.
Based on the logs and on the bug it seems that the reason is PipeWire not broadcasting the default device change signal even if at the end of the day the default device actually changed. Otherwise you would see EasyEffects printing lines about the "new default device".
I wonder if usb devices make PipeWire behave differently somehow. When I switch the default device between my onboard card and the hdmi cards on my gpu everything is fine. Even if I disable the cards in Pavucontrol nothing breaks. It seems that having an external usb device that can actually be turned off on the hardware level changes something...
@wwmm I agree that it's probably pipewire (or some other system component); since the device is not simply disabled, it's gone, there must be some hidden complexity in identifying that the same device was plugged back in, and should be made default automatically.
But why instead clients are able to play again on the right device without Easy effects?
But why instead clients are able to play again on the right device without Easy effects?
That is easy to understand. WirePlumber and PipeWire always know which is the default device because they are the ones managing them. But clients like EasyEffects will only know about a new device if PipeWire emits a signal to broadcast the change. If this signal does not come EasyEffects will behave like nothing happened. What so far seems to be the case.
That is easy to understand. WirePlumber and PipeWire always know which is the default device because they are the ones managing them.
WirePlumber is the one moving streams to the correct devices. In EasyEffects when you "enable effects" to a stream what happens at the end of the day is that we ask wireplumber to move the stream to our virtual devices. So as long as a link is managed directly by wireplumber things will always work. That is the case for links between streams and devices.
But links involving filters require manual management. Unfortunately... These ones EasyEffects has to create itself. And for that it needs to know the correct output device.
You should be able to see by just looking what device has the checkmark button enabled in pavucontrol
No I meant the event that you are looking for as the default with wpctl status is always correct
No I meant the event that you are looking for as the default with wpctl status is always correct
When you run EE in debug mode you will see at the beginning of its logs lines similar to these ones
pipe_manager.cpp:955 new metadata property: 0, default.configured.audio.sink, Spa:String:JSON, {"name":"bluez_output.40_C1_F6_5F_8B_4F.1"}
pipe_manager.cpp:955 new metadata property: 0, default.configured.audio.source, Spa:String:JSON, {"name":"alsa_input.usb-BEHRINGER_C-1U-00.analog-stereo"}
pipe_manager.cpp:955 new metadata property: 0, default.audio.sink, Spa:String:JSON, {"name":"alsa_output.usb-Generic_USB_Audio-00.HiFi__hw_Audio_2__sink"}
pipe_manager.cpp:955 new metadata property: 0, default.audio.source, Spa:String:JSON, {"name":"alsa_output.usb-Generic_USB_Audio-00.HiFi__hw_Audio_2__sink"}
After this when you change the default in a program like pavucontrol lines similar to these ones are shown
pipe_manager.cpp:955 new metadata property: 0, default.configured.audio.sink, Spa:String:JSON, { "name": "alsa_output.pci-0000_0f_00.1.hdmi-stereo" }
pipe_manager.cpp:955 new metadata property: 0, default.audio.sink, Spa:String:JSON, {"name":"alsa_output.pci-0000_0f_00.1.hdmi-stereo"}
application.cpp:80 new default output device: alsa_output.pci-0000_0f_00.1.hdmi-stereo
Pay attention to the log message that starts with "new default output device". The absence of a line like this one in your logs is probably related to the bug.
What I don't understand is that I see the device in the EE dropdown list when it is again power on but it is not the default one. So you see in the device list but not as the default?
is it here? https://github.com/wwmm/easyeffects/blob/68fe843746dde0419cbe0612eab5632185e1d912/src/pipe_manager_box.cpp#L621-L640
An interesting hint.. when we put down the usb device we don't have any default sinks with wpctl status so when we put the device on it is going to be back as the default in wpctl status.
So it is a sort of orphan when it is off and then it is just recovered... this why we don't have a new default event.
What I don't understand is that I see the device in the EE dropdown list when it is again power on but it is not the default one. So you see in the device list but not as the default?
Just seeing that the device is there is not enough. There has to be a reason for EE to use it. Either the user manually selected it as custom output device or the device is the system default device.
So I think that we need to manage this on our side right?
I think that what makes sense to be done on our side is already there. If EE is set to use the default PipeWire just has to tell which device is default. And if EE is configured to use a custom device all that is needed is that the device comes back with the same node name https://github.com/wwmm/easyeffects/blob/68fe843746dde0419cbe0612eab5632185e1d912/src/stream_output_effects.cpp#L195.
But it seems that both conditions are somehow false...
An interesting hint.. when we put down the usb device we don't have any default sinks with wpctl status
I do not think that it is possible to actually not have a default device. Wpctl may be showing just what was explicitly set byt the user and not what wireplumber does on its own. For example plenty of EE users had problems caused by the fact wireplumber decided to set EE virtual devices as default without asking. There is definitely something set as default.
is it here?
The code at line 621 will only be executed if PipeWire emits the default device changed signal.
And if EE is configured to use a custom device all that is needed is that the device comes back with the same node name
I did some tests with my soundcards and I see now that this is not going to work. The reason is that if the device disappears we have to do something. And the "something" at this moment is setting the output device to the default device. So even if the other device comes back EE internal variable has already been updated with the default device name...
The problem is that it does not make sense to keep the output device variable set to a node that may never come back. So the ideal solution would be the default device signal to be triggered when the external usb device is turned on again.
An interesting hint.. when we put down the usb device we don't have any default sinks with wpctl status >so when we put the device on it is going to be back as the default in wpctl status. So it is a sort of orphan when it is off and then it is just recovered... this why we don't have a new default >event.
Hum... But if it was "just recovered" I would assume that the previous default device information that was set would still be useful. But if EasyEffects automatically switched to your onboard card after the usb device was turned off then pipewire probably emitted a signal telling that the default device is another. Are you sure that your log does not have any line about default device changes?
But if EasyEffects automatically switched to your onboard card after the usb device was turned off then pipewire probably emitted a signal telling that the default device is another. Are you sure that your log does not have any line about default device changes?
If you recheck the device off log at https://github.com/wwmm/easyeffects/issues/2920#issuecomment-1946615255
We don't have any new default just a termination of the usb one. it is consistent with wpctl status with no * on all the other sinks.
Then it is recovered after the device on with no new default event as IMHO it never changed.
So my opinion is that the EE logic need to be that when an new event Audio/Sink 97 alsa_output.usb-<mydevice> with serial 2790 has been added is retrieved we need to check if it was the last default and if any new default event was received in the meantime we need to re-connect that one.
Another note just using a client without EE. In helvum I see that the client is switched to the internal device when the usb is goin off but still no * in wpctl status.
When the usb device is on again in helvum I see the client connected back to the usb device and the * is on the usb device with wpctl status.