Easyeffect doesn't recconect to the "default" device #2920

bhack · 2024-02-15T15:46:27Z

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

Paste your log here

Additional Information

No response

The text was updated successfully, but these errors were encountered:

wwmm · 2024-02-15T15:50:39Z

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.

bhack · 2024-02-15T16:09:37Z

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()

wwmm · 2024-02-15T16:55:23Z

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?

wwmm · 2024-02-15T16:58:18Z

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.

bhack · 2024-02-15T17:08:09Z

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()

wwmm · 2024-02-15T17:43:07Z

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?

bhack · 2024-02-15T18:03:31Z

. 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.

bhack · 2024-02-15T19:35:29Z

Could this be related to https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/384?

But it seems it was fixed a long time ago.

bhack · 2024-02-15T19:37:44Z

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

wwmm · 2024-02-15T20:15:21Z

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.

wwmm · 2024-02-15T20:20:26Z

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...

violetmage · 2024-02-15T20:26:06Z

@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.

bhack · 2024-02-15T21:05:49Z

But why instead clients are able to play again on the right device without Easy effects?

wwmm · 2024-02-15T21:16:35Z

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.

wwmm · 2024-02-15T21:21:32Z

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.

bhack · 2024-02-15T21:38:46Z

How can we debug what the current default device is?

violetmage · 2024-02-15T22:11:36Z

You should be able to see by just looking what device has the checkmark button enabled in pavucontrol

bhack · 2024-02-15T22:15:04Z

No I meant the event that you are looking for as the default with wpctl status is always correct

wwmm · 2024-02-15T22:49:02Z

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.

bhack · 2024-02-15T22:56:08Z

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?

easyeffects/src/pipe_manager_box.cpp

Lines 621 to 640 in 68fe843

    
           self->data->connections.push_back(pm->new_default_sink_name.connect([=](const std::string new_default_device_name) { 
        
             if (gtk_switch_get_state(self->use_default_output) != 1) { 
        
               return; 
        
             } 
        
             for (guint n = 0U; n < g_list_model_get_n_items(G_LIST_MODEL(self->output_devices_model)); n++) { 
        
               auto* holder = 
        
                   static_cast<ui::holders::NodeInfoHolder*>(g_list_model_get_item(G_LIST_MODEL(self->output_devices_model), n)); 
        
               if (holder->info->name == new_default_device_name) { 
        
                 g_object_unref(holder); 
        
                 gtk_drop_down_set_selected(self->dropdown_output_devices, n); 
        
                 return; 
        
               } 
        
               g_object_unref(holder); 
        
             } 
        
           }));

bhack · 2024-02-15T23:05:31Z

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.

bhack · 2024-02-15T23:06:48Z

So I think that we need to manage this on our side right?

wwmm · 2024-02-16T00:50:28Z

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

easyeffects/src/stream_output_effects.cpp

Line 195 in 68fe843

if (node.name == output_device_name) {

.

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.

wwmm · 2024-02-16T00:54:43Z

is it here?

The code at line 621 will only be executed if PipeWire emits the default device changed signal.

wwmm · 2024-02-16T01:00:58Z

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...

wwmm · 2024-02-16T01:02:31Z

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.

wwmm · 2024-02-16T01:08:29Z

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?

bhack · 2024-02-16T01:12:02Z

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 #2920 (comment)

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.

bhack · 2024-02-16T01:15:09Z

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.

bhack · 2024-02-20T21:20:33Z

It emits this signal for all my usb microphones and also for my bluetooth headset. Why can't it do the same to your usb card? It does not make sense.

But it is not only related to USB. If am going to manually set EE to the internal device and I disable it with pavucontrol it is going to fallback to the 2nd one in the list. When I re-enable the internal device with pavucontrol it stay locked to the old 2nd one in the EE list.

So are we doing something wrong in EE flatpack?

wwmm · 2024-02-20T21:58:42Z

If am going to manually set EE to the internal device and I disable it with pavucontrol it is going to fallback to the 2nd one in the list

This is a different thing. When Use Default is disabled it is normal to have what is selected in the dropdown as the value stored at output-device. Once the previously selected device is removed something else is selected. It does not make sense to stay in a device that does not exist anymore.

The manual selection completely disables the use of the automatic switch to the default device. The current default not necessarily being used in the manual mode can even be what is desired in systems with multiple cards. The real issue here is happening when Use Default Output is enabled. This is the mode that is supposed to automatically switch to the current default but is not being able to do it because the signal is not coming.

bhack · 2024-02-20T22:11:31Z

I understand your logic but the point, with all the tests that we have done (and I've just checked it again) is that also when I set the system default to the internal one and I disable it with pavucontrol we don't receive what you exepect pipe_manager.cpp:955.

This why I think it has something to do with flatpack and not a usb specific pipewire issue.

wwmm · 2024-02-20T22:53:45Z

I understand your logic but the point, with all the tests that we have done (and I've just checked it again) is that also when I set the system default to the internal one and I disable it with pavucontrol we don't receive what you exepect pipe_manager.cpp:955.

Yes. This shouldn't be happening to the onboard card too.

This why I think it has something to do with flatpack and not a usb specific pipewire issue.

But somehow it does not seem to be happening to all Flatpak users. So we are still missing something.

bhack · 2024-02-20T23:07:20Z

It is something else as I've tested with a non flatpack EE and I don't see pipe_manager.cpp:955 with pavucontrol enable/disable

wwmm · 2024-02-20T23:17:02Z

I have updated the master branch with a fix for the dropdown messing with the output-device property when it does not make sense for it to be doing it. In other words when Use Default is enabled. After some time a Flatpak package will be available at the bottom of this page https://github.com/wwmm/easyeffects/actions/runs/7981296388.

It is something else as I've tested with a non flatpack EE and I don't see pipe_manager.cpp:955 with pavucontrol enable/disable

Ok. So we can exclude a Flatpak issue.

wwmm · 2024-02-20T23:18:06Z

It is something else as I've tested with a non flatpack EE and I don't see pipe_manager.cpp:955 with pavucontrol enable/disable

Did you see that "spa_pod_array" error outside of Flatpak too?

bhack · 2024-02-20T23:42:06Z

Yes

Also if we don't use pavucontrol enable/disable but the official gnome device selection we always correctly receive pipe_manager.cpp:955both in flatpack and standalone mode.

wwmm · 2024-02-21T00:17:29Z

Also if we don't use pavucontrol enable/disable but the official gnome device selection we always correctly receive pipe_manager.cpp:955both in flatpack and standalone mode.

Strange. As far as I know both programs are still Pulseaudio apps and should be using the same functions to deal with devices. It is unexpected that they lead to different results.

bhack · 2024-02-21T00:36:35Z

I don't know if it is the same or not but if I switch the sink command line with
wpctl set-default <id> we always receive pipe_manager.cpp:955 exactly as it happen with the gnome default device selector.

So disable and enable the device with pavucontrol is not the same.

wwmm · 2024-02-21T00:46:25Z

So disable and enable the device with pavucontrol is not the same.

I understand wpctl leading to different results because it is probably using PipeWire's native API instead of the Pulseaudio compatibility layer. But gnome causing something different to happen is a surprise. Could it be they are already using native PipeWire functions instead of the compatibility layer??

wwmm · 2024-02-21T00:47:53Z

In any case I do not think that Pulseaudio's compatibility layer should be broken. It is supposed to just work for things related to default device management.

bhack · 2024-02-21T01:03:07Z

Gnome shell is calling (with the gjs introspection) this underline function when we switch the device:
https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/blob/master/gvc-mixer-control.c#L597

wwmm · 2024-02-21T01:07:56Z

Gnome shell is calling (with the gjs introspection) this underline function when we switch the device: https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/blob/master/gvc-mixer-control.c#L597

I looked at the code in gnome's gvc libray and it still uses Pulseaudio's calls. So PipeWire's compatibility layer does not seem to the what is causing the difference.

bhack · 2024-02-21T01:15:09Z

What I can tell you is that in pavucontrol changing the device on the speech-dispatcher-dummy is going to create pipe_manager.cpp:955 instead disabling and enabling the device in pavucontrol is not going to generate that event

bhack · 2024-02-21T11:56:32Z

Also I want to confirm that switching device with the Gnome official selector:
https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/blob/master/gvc-mixer-control.c#L597

It is going to effectively change the wireplumber default wpctl status and it is also aligned with pactl get-default-sink and we receive pipe_manager.cpp:955.

Instead switching on and off the device from pavucontrol is going to have no effect on wpctl status and an effected only on pactl get-default-sink. So in that case the two command are misaligned and we don't receive pipe_manager.cpp:955.

So it seems that the pulseaudio API called by pavucontrol enable/disable has not the same effect as switching the device (same behavior as physically turn the device on/off).

Do you know what is it calling as I don't find exactly the widget?
https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/tree/master/src?ref_type=heads

wwmm · 2024-02-21T23:37:24Z

Do you know what is it calling as I don't find exactly the widget?

In Pavucontrol we change the card profile to off to disable it. They seem to do this in this line https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/blob/master/src/cardwidget.cc?ref_type=heads#L125 through a call to pa_context_set_card_profile_by_index. What based on the Pulseaudio function name seems a good choice.

wwmm · 2024-02-21T23:39:59Z

So it seems that the pulseaudio API called by pavucontrol enable/disable has not the same effect as switching the device (same behavior as physically turn the device on/off).

I am not sure I understand. Switching devices and changing card profiles are very different operations.

bhack · 2024-02-21T23:45:30Z

I meant that switching the device profile to off we don't have any pipe_manager.cpp:955 similar to when we physically power off and on the device. At the same time in this case wpctl status and pactl get-default-sink are misaligned.

Instead they are aligned and we regularly receive pipe_manager.cpp:955:

When I switch the default device in the gnome device selector (gvc library call)
When we change the device in pavucontrol for speech-dispatcher-dummy

bhack · 2024-03-05T15:59:44Z

I know that with workaround that we have in main it will solve when the default device is not manually selected in EasyEffect UI but do you want to investigate more on the general case? What do you think about my last message?

wwmm · 2024-03-05T16:13:41Z

I know that with workaround that we have in main it will solve when the default device is not manually selected in EasyEffect UI but do you want to investigate more on the general case? What do you think about my last message?

I think that just like it happened in #2951 we will need some feedback from PipeWire's or WirePlumber's developers about the facts at #2920 (comment). Some kind of corner case not well handled by the audio server is at play here.

bhack · 2024-03-05T16:38:54Z

Mhh but I don't know exactly how to describe this issue on pipewire or wireplumber cause I don't know what is the expected behavior. Cause what I see in wpctl status is that the default is not changed over on and off until your are going to manually change the device.

wwmm · 2024-03-05T17:23:04Z

Mhh but I don't know exactly how to describe this issue on pipewire or wireplumber cause I don't know what is the expected behavior. Cause what I see in wpctl status is that the default is not changed over on and off until your are going to manually change the device.

I think that there are two things that are not making sense in the server behavior. The first is why the default device shown by wpctl is not what is actualy being used as default in some situations. And the second is why the "default device changed" signal is not emitted when your usb card is switched on/off. Be it through the profile selection or through physically removing and attaching the usb device. If a usb device is plugged in the system and it is supposed to be the default after initialization I would expect the server to notify the clients about the new default device selection.

bhack · 2024-03-05T17:35:31Z

If a usb device is plugged in the system and it is supposed to be the default after initialization I would expect the server to notify the clients about the new default device selection.

Are you sure about this? Is this in the wireplumber or in the pipewire ownership? Cause if this is in the wireplumber ownership this doesn't seem to be its logic as it doesn't change the default and it could recover it when the device is on without any notification of new default.

wwmm · 2024-03-05T20:58:15Z

Are you sure about this? Is this in the wireplumber or in the pipewire ownership? Cause if this is in the wireplumber ownership this doesn't seem to be its logic as it doesn't change the default and it could recover it when the device is on without any notification of new default.

PipeWire and WirePlumber are doing it on my computer. It does not matter which program I use to set the default. The signal about default device changes is always emitted when plug/unplug my bluetooth headset or usb microphone. The signal is emitted even if the default device change was triggered without manual intervention. For example if my bluetooth device is plugged and I turn it off my onboard card becomes the default automatically. And the signal is emitted without the need for me to set anything manually. That is what should be happening on your setup.

bhack · 2024-03-05T21:58:47Z

Before opening an upstream Pipewire ticket let see if @wtay can give us a feedback here.

bhack · 2024-03-06T15:52:40Z

In the meantime I have also a ticket on wireplumber:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/588

bhack · 2024-03-12T11:11:23Z

@wwmm The different behavior we had between the two systems probably it is fixed in wireplumber https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/615

bhack · 2024-03-22T17:33:17Z

Fixed in wireplumber 0.5.0

wwmm mentioned this issue Feb 15, 2024

Audio doesn't work after waking from sleep. #2480

Open

bhack closed this as completed Mar 22, 2024

Easyeffect doesn't recconect to the "default" device #2920

Easyeffect doesn't recconect to the "default" device #2920

Comments

bhack commented Feb 15, 2024

EasyEffects Version

What package are you using?

Distribution

Describe the bug

Expected Behavior

Debug Log

Additional Information

wwmm commented Feb 15, 2024

bhack commented Feb 15, 2024

wwmm commented Feb 15, 2024

wwmm commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024 • edited Loading

wwmm commented Feb 15, 2024

bhack commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024

wwmm commented Feb 15, 2024

wwmm commented Feb 15, 2024

violetmage commented Feb 15, 2024

bhack commented Feb 15, 2024

wwmm commented Feb 15, 2024

wwmm commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024

violetmage commented Feb 15, 2024

bhack commented Feb 15, 2024 • edited Loading

wwmm commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024 • edited Loading

bhack commented Feb 15, 2024

wwmm commented Feb 16, 2024

wwmm commented Feb 16, 2024

wwmm commented Feb 16, 2024 • edited Loading

wwmm commented Feb 16, 2024

wwmm commented Feb 16, 2024

bhack commented Feb 16, 2024 • edited Loading

bhack commented Feb 16, 2024

bhack commented Feb 20, 2024 • edited Loading

wwmm commented Feb 20, 2024

bhack commented Feb 20, 2024

wwmm commented Feb 20, 2024

bhack commented Feb 20, 2024

wwmm commented Feb 20, 2024

wwmm commented Feb 20, 2024

bhack commented Feb 20, 2024

wwmm commented Feb 21, 2024

bhack commented Feb 21, 2024

wwmm commented Feb 21, 2024 • edited Loading

wwmm commented Feb 21, 2024

bhack commented Feb 21, 2024 • edited Loading

wwmm commented Feb 21, 2024 • edited Loading

bhack commented Feb 21, 2024 • edited Loading

bhack commented Feb 21, 2024

wwmm commented Feb 21, 2024

wwmm commented Feb 21, 2024

bhack commented Feb 21, 2024 • edited Loading

bhack commented Mar 5, 2024

wwmm commented Mar 5, 2024 • edited Loading

bhack commented Mar 5, 2024

wwmm commented Mar 5, 2024 • edited Loading

bhack commented Mar 5, 2024 • edited Loading

wwmm commented Mar 5, 2024 • edited Loading

bhack commented Mar 5, 2024

bhack commented Mar 6, 2024

bhack commented Mar 12, 2024 • edited Loading

bhack commented Mar 22, 2024

wwmm commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

wwmm commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

wwmm commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

bhack commented Feb 15, 2024 •

edited

Loading

wwmm commented Feb 16, 2024 •

edited

Loading

bhack commented Feb 16, 2024 •

edited

Loading

bhack commented Feb 20, 2024 •

edited

Loading

wwmm commented Feb 21, 2024 •

edited

Loading

bhack commented Feb 21, 2024 •

edited

Loading

wwmm commented Feb 21, 2024 •

edited

Loading

bhack commented Feb 21, 2024 •

edited

Loading

bhack commented Feb 21, 2024 •

edited

Loading

wwmm commented Mar 5, 2024 •

edited

Loading

wwmm commented Mar 5, 2024 •

edited

Loading

bhack commented Mar 5, 2024 •

edited

Loading

wwmm commented Mar 5, 2024 •

edited

Loading

bhack commented Mar 12, 2024 •

edited

Loading