Audio doesn't work after waking from sleep.

[tazihad]

EasyEffects Version

7.0.6

What package are you using?

Flatpak (Flathub)

Distribution

Fedora Kinoite 38

Describe the bug

I have applied the convolver effect from here. When laptop is wake from sleep. Audio doesn't work. It used to work in older versions. But if I disable the effect sound works again.

Expected Behavior

No response

Debug Log

No response

Additional Information

No response

[wwmm]

It is probably related to #1083. Since the time we used Pulseaudio the bugs related to suspension/hibernation are still a mystery. For some reason they only happen on some computers but never on others.

[BayouGuru67]

I am experiencing the same issue here, but I am fairly certain it is not an issue with EasyEffects at all. It's a PipeWire/PulseAudio/ALSA/X(?) thing, as JamesDSP effects is affected in exactly the same way as EasyEffects.

The core description of the problem is that something happens when you turn off the monitor, switch to a different input on an A/V Receiver (on which the affected PC is one input), or let the monitor/PC go into power saving mode. In all of those cases, it seems that all of the "connections" to pipewire by these audio processing programs are broken/forgotten. In order to restore them, one must exit EasyEffects or JamesDSP and then restart whichever one you're wanting to run. It may not be necessary to restart the source playing the audio.

You CAN NOT have EasyEffects/JamesDSP set to run in the background continuously, you will simply lose all audio output on the system until you kill/exit the effects program after each power management event as described above.

[wwmm]

What really puzzles me the most is that this bug seems to somehow to depend on the hardware. I have never been able to reproduce it when putting my desktop to sleep while other people see it frequently. It was the same thing on Pulseaudio.

[carolfs]

I've been having this issue for a while, also using Flatpak on Fedora Silverblue 38. It started recently. FYI:

$ lspci -nn | grep -i audio
00:1f.3 Multimedia audio controller [0401]: Intel Corporation Comet Lake PCH-LP cAVS [8086:02c8]

[wwmm]

The only case where I understand the sound being gone after suspending is when PipeWire dies and restarts itself when the computer is resuming operations. EasyEffects has to be killed and restarted manually when the server dies. But as far as I remember there are cases where there is no evidence that the serve died. Some help from PipeWire's developers will be needed in these cases because the plugins state is handled directly by the server.

[carolfs]

I've tried downgrading EasyEffects to 6.3.0 and switching to a Fedora deployment from 1 July 2023 that uses Pipewire 0.3.72. Everything worked fine. But either upgrading EasyEffects to 7.0.7 or switching Fedora to a 28 August 2023 deployment that uses Pipewire 0.3.78 made the bug appear again.

[wwmm]

I've tried downgrading EasyEffects to 6.3.0

This version probably uses GStreamer to handle the effects pipeline instead of using native PipeWire filters. But in PulseEffects where the pipeline was also managed through GStreamer the same problem happened when the computer was suspended. Even after switching to another audio server and implementing the effects pipeline in a whole different way this bug can still happen. That is really weird.

[Innarel]

It happens both in the flatpak and apt versions. The only solution is to "easyeffects -q" and then run it again.

[BayouGuru67]

As of or prior to PipeWire version update to 0.3.79 and EasyEffects update to 7.1.0, the problem as originally described has changed. Power management is no longer an issue. The only time the issue occurs now is when I switch away from the computer's input on the A/V receiver, whether for a short or long while makes no difference. It seems that when the HDMI connection is terminated, so is the audio connection and it does not automatically reestablish upon reconnection. The problems of losing one side of audio or getting distorted audio in this situation seems to have been addressed. I still cannot run EasyEffects (or JamesDSP) as a service all the time because if/when I have to switch A/V receiver inputs, I have to close and then reopen EasyEffects to get audio back. FWIW, when this issue is happening, I can see that EasyEffects does see the audio on its input and is processing it, but it doesn't make it out of the machine until I stop and restart EasyEffects.

As an aside: Is there a reason EasyEffects is still reporting version 0.3.69 of Pipewire when I am running version 0.3.79?

[wwmm]

Is there a reason EasyEffects is still reporting version 0.3.69 of Pipewire when I am running version 0.3.79?

One of the versions reported is retrived through pw_get_headers_version. It is a PipeWire function that returns the PipeWire version used when EasyEffects was compiled. In the end the version used is the one installed in your system.

[carolfs]

This has been happening to me again on Fedora Silverblue 39, Pipewire 1.0.0 and Easy Effects 7.1.3. The only solution, as mentioned above, is to run easyeffects -q and restart the app.

[wwmm]

This has been happening to me again on Fedora Silverblue 39, Pipewire 1.0.0 and Easy Effects 7.1.3. The only solution, as mentioned above, is to run easyeffects -q and restart the app.

@carolfs When you look at the output of journalctl do you see any message indicating that PipeWire's process died? When this problem happened on Pulseaudio there were some cases where the server died during the suspension for some reason.

[carolfs]

I ran journalctl -r | grep pipewire | less and there was nothing about pipewire in the relevant timeframe, but audio had stopped working.

[wwmm]

Considering that the current situation is exactly the same PulseEffects faced on Pulseaudio the only thing I can think of is that somehow drivers matter or that some of the code PipeWire reused from Pulseaudio does not play nice with computer suspension in some circumstances.

[wwmm]

Something came to my mind now. Maybe PipeWire is recreating the audio device when the computer wakes and is not broadcast the event. If this is the case we should see the sound card node id changing before and after the sleep. The people that can reproduce the issue (I still can't) can run

pw-cli list-objects Node

before and after the sleep. This command will show a list of nodes and their id number.

[wwmm]

Another test is running pw-dot when there is no sound so we can see the links between filters and devices as well as their state. The file created by pw-dot can be viewed with the command xdot.

[carolfs]

I did that. Output of pw-dot before suspend:

before

``` id 28, type PipeWire:Interface:Node/3 object.serial = "28" factory.id = "10" priority.driver = "20000" node.name = "Dummy-Driver" id 29, type PipeWire:Interface:Node/3 object.serial = "29" factory.id = "10" priority.driver = "19000" node.name = "Freewheel-Driver" id 37, type PipeWire:Interface:Node/3 object.serial = "37" factory.id = "10" client.id = "33" priority.session = "100" priority.driver = "1" node.name = "Midi-Bridge" media.class = "Midi/Bridge" id 45, type PipeWire:Interface:Node/3 object.serial = "142" object.path = "alsa:pcm:0:hw:sofhdadsp:playback" factory.id = "18" client.id = "33" device.id = "63" priority.session = "1000" priority.driver = "1000" node.description = "Comet Lake PCH-LP cAVS Speaker + Headphones" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink" node.nick = "Speaker + Headphones" media.class = "Audio/Sink" id 53, type PipeWire:Interface:Node/3 object.serial = "137" object.path = "v4l2:/dev/video0" factory.id = "10" client.id = "33" device.id = "42" priority.session = "1000" node.description = "Integrated_Webcam_HD (V4L2)" node.name = "v4l2_input.pci-0000_00_14.0-usb-0_6_1.0" node.nick = "Integrated_Webcam_HD" media.class = "Video/Source" media.role = "Camera" id 54, type PipeWire:Interface:Node/3 object.serial = "140" object.path = "alsa:pcm:0:hw:sofhdadsp,4:playback" factory.id = "18" client.id = "33" device.id = "63" priority.session = "680" priority.driver = "680" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 2 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_4__sink" node.nick = "HDMI / DisplayPort 2 Output" media.class = "Audio/Sink" id 55, type PipeWire:Interface:Node/3 object.serial = "141" object.path = "alsa:pcm:0:hw:sofhdadsp,3:playback" factory.id = "18" client.id = "33" device.id = "63" priority.session = "696" priority.driver = "696" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 1 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_3__sink" node.nick = "HDMI / DisplayPort 1 Output" media.class = "Audio/Sink" id 57, type PipeWire:Interface:Node/3 object.serial = "143" object.path = "alsa:pcm:0:hw:sofhdadsp:capture" factory.id = "18" client.id = "33" device.id = "63" priority.session = "2000" priority.driver = "2000" node.description = "Comet Lake PCH-LP cAVS Headset Mono Microphone + Headphones Stereo Microphone" node.name = "alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__source" node.nick = "Headset Mono Microphone + Headphones Stereo Microphone" media.class = "Audio/Source" id 64, type PipeWire:Interface:Node/3 object.serial = "144" object.path = "alsa:pcm:0:hw:sofhdadsp,6:capture" factory.id = "18" client.id = "33" device.id = "63" priority.session = "1648" priority.driver = "1648" node.description = "Comet Lake PCH-LP cAVS Digital Microphone" node.name = "alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_6__source" node.nick = "Digital Microphone" media.class = "Audio/Source" id 65, type PipeWire:Interface:Node/3 object.serial = "139" object.path = "alsa:pcm:0:hw:sofhdadsp,5:playback" factory.id = "18" client.id = "33" device.id = "63" priority.session = "664" priority.driver = "664" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 3 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_5__sink" node.nick = "HDMI / DisplayPort 3 Output" media.class = "Audio/Sink" id 81, type PipeWire:Interface:Node/3 object.serial = "167" factory.id = "18" client.id = "80" priority.session = "0" node.description = "Easy Effects Sink" node.name = "easyeffects_sink" media.class = "Audio/Sink" id 85, type PipeWire:Interface:Node/3 object.serial = "168" factory.id = "18" client.id = "80" priority.session = "0" node.description = "Easy Effects Source" node.name = "easyeffects_source" media.class = "Audio/Source/Virtual" id 91, type PipeWire:Interface:Node/3 object.serial = "177" client.id = "80" node.description = "Output Level Meter" node.name = "ee_soe_output_level" node.nick = "output_level" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 96, type PipeWire:Interface:Node/3 object.serial = "182" client.id = "80" node.description = "Spectrum" node.name = "ee_soe_spectrum" node.nick = "spectrum" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 114, type PipeWire:Interface:Node/3 object.serial = "477" client.id = "80" node.description = "Equalizer" node.name = "ee_soe_equalizer" node.nick = "equalizer" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 146, type PipeWire:Interface:Node/3 object.serial = "490" factory.id = "6" client.id = "79" client.api = "pipewire-pulse" application.name = "spotify" node.name = "spotify" media.class = "Stream/Output/Audio" media.role = "Music" id 149, type PipeWire:Interface:Node/3 object.serial = "235" client.id = "80" node.description = "Output Level Meter" node.name = "ee_sie_output_level" node.nick = "output_level" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 154, type PipeWire:Interface:Node/3 object.serial = "240" client.id = "80" node.description = "Spectrum" node.name = "ee_sie_spectrum" node.nick = "spectrum" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 164, type PipeWire:Interface:Node/3 object.serial = "470" client.id = "80" node.description = "Loudness" node.name = "ee_soe_loudness" node.nick = "loudness" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 165, type PipeWire:Interface:Node/3 object.serial = "305" client.id = "80" node.description = "Easy Effects Filter" node.name = "ee_test_signals" media.type = "Audio" media.category = "Source" media.role = "DSP" ```

Output after suspend:

after

``` id 28, type PipeWire:Interface:Node/3 object.serial = "28" factory.id = "10" priority.driver = "20000" node.name = "Dummy-Driver" id 29, type PipeWire:Interface:Node/3 object.serial = "29" factory.id = "10" priority.driver = "19000" node.name = "Freewheel-Driver" id 37, type PipeWire:Interface:Node/3 object.serial = "37" factory.id = "10" client.id = "33" priority.session = "100" priority.driver = "1" node.name = "Midi-Bridge" media.class = "Midi/Bridge" id 41, type PipeWire:Interface:Node/3 object.serial = "503" object.path = "alsa:pcm:0:hw:sofhdadsp,4:playback" factory.id = "18" client.id = "33" device.id = "42" priority.session = "680" priority.driver = "680" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 2 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_4__sink" node.nick = "HDMI / DisplayPort 2 Output" media.class = "Audio/Sink" id 44, type PipeWire:Interface:Node/3 object.serial = "505" object.path = "alsa:pcm:0:hw:sofhdadsp:playback" factory.id = "18" client.id = "33" device.id = "42" priority.session = "1000" priority.driver = "1000" node.description = "Comet Lake PCH-LP cAVS Speaker + Headphones" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink" node.nick = "Speaker + Headphones" media.class = "Audio/Sink" id 45, type PipeWire:Interface:Node/3 object.serial = "507" object.path = "alsa:pcm:0:hw:sofhdadsp,6:capture" factory.id = "18" client.id = "33" device.id = "42" priority.session = "1648" priority.driver = "1648" node.description = "Comet Lake PCH-LP cAVS Digital Microphone" node.name = "alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_6__source" node.nick = "Digital Microphone" media.class = "Audio/Source" id 49, type PipeWire:Interface:Node/3 object.serial = "502" object.path = "alsa:pcm:0:hw:sofhdadsp,5:playback" factory.id = "18" client.id = "33" device.id = "42" priority.session = "664" priority.driver = "664" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 3 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_5__sink" node.nick = "HDMI / DisplayPort 3 Output" media.class = "Audio/Sink" id 50, type PipeWire:Interface:Node/3 object.serial = "506" object.path = "alsa:pcm:0:hw:sofhdadsp:capture" factory.id = "18" client.id = "33" device.id = "42" priority.session = "2000" priority.driver = "2000" node.description = "Comet Lake PCH-LP cAVS Headset Mono Microphone + Headphones Stereo Microphone" node.name = "alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__source" node.nick = "Headset Mono Microphone + Headphones Stereo Microphone" media.class = "Audio/Source" id 51, type PipeWire:Interface:Node/3 object.serial = "500" object.path = "v4l2:/dev/video0" factory.id = "10" client.id = "33" device.id = "52" priority.session = "1000" node.description = "Integrated_Webcam_HD (V4L2)" node.name = "v4l2_input.pci-0000_00_14.0-usb-0_6_1.0" node.nick = "Integrated_Webcam_HD" media.class = "Video/Source" media.role = "Camera" id 57, type PipeWire:Interface:Node/3 object.serial = "504" object.path = "alsa:pcm:0:hw:sofhdadsp,3:playback" factory.id = "18" client.id = "33" device.id = "42" priority.session = "696" priority.driver = "696" node.description = "Comet Lake PCH-LP cAVS HDMI / DisplayPort 1 Output" node.name = "alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_3__sink" node.nick = "HDMI / DisplayPort 1 Output" media.class = "Audio/Sink" id 81, type PipeWire:Interface:Node/3 object.serial = "167" factory.id = "18" client.id = "80" priority.session = "0" node.description = "Easy Effects Sink" node.name = "easyeffects_sink" media.class = "Audio/Sink" id 85, type PipeWire:Interface:Node/3 object.serial = "168" factory.id = "18" client.id = "80" priority.session = "0" node.description = "Easy Effects Source" node.name = "easyeffects_source" media.class = "Audio/Source/Virtual" id 91, type PipeWire:Interface:Node/3 object.serial = "177" client.id = "80" node.description = "Output Level Meter" node.name = "ee_soe_output_level" node.nick = "output_level" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 96, type PipeWire:Interface:Node/3 object.serial = "182" client.id = "80" node.description = "Spectrum" node.name = "ee_soe_spectrum" node.nick = "spectrum" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 146, type PipeWire:Interface:Node/3 object.serial = "490" factory.id = "6" client.id = "79" client.api = "pipewire-pulse" application.name = "spotify" node.name = "spotify" media.class = "Stream/Output/Audio" media.role = "Music" id 149, type PipeWire:Interface:Node/3 object.serial = "235" client.id = "80" node.description = "Output Level Meter" node.name = "ee_sie_output_level" node.nick = "output_level" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 154, type PipeWire:Interface:Node/3 object.serial = "240" client.id = "80" node.description = "Spectrum" node.name = "ee_sie_spectrum" node.nick = "spectrum" media.type = "Audio" media.category = "Filter" media.role = "DSP" id 165, type PipeWire:Interface:Node/3 object.serial = "305" client.id = "80" node.description = "Easy Effects Filter" node.name = "ee_test_signals" media.type = "Audio" media.category = "Source" media.role = "DSP" ```

The file created by pw-dot (renamed so that I could attach it). pw.dot

[rscm]

The people that can reproduce the issue (I still can't) can run

pw-cli list-objects Node

before and after the sleep. This command will show a list of nodes and their id number.

• here without easyeffects open, before and after suspend (I had audio after) pw_before.txt pw_after.txt

• here with easyeffects open, before and after suspend (no audio after) pw_before_ee.txt pw_after_ee.txt

• dot file and png render (no audio) pw.zip

[wwmm]

I've looked at @carolfs and @rscm files and the difference between the pw-dot output is so significant I am not sure what to conclude about them :smile:. But let's start with what is similar. The output of pw-cli list-objects Node.

In both systems the id number number of the sound card sink device changed after the computer came back from sleep. This indicates that the sound server (PipeWire) had to destroy the device and recreate it for some reason. It depends on the hardware/driver. The same kind of thing also happens on Pulseaudio for reasons I could never understand.

Now let's compare this to what happens on my desktop. Where the audio comes back own its own just fine. The id number here remains the same. So my guess at this moment is that something bad is happening in the systems where PipeWire has to recreate the device when it comes back from sleep. The question now is what. At this moment I can think of two possibilities that are both hard to fix:

1. PipeWire is not broadcasting the new device created after the computer wakes.
2. PipeWire broadcasts it but this happens before the system finishes bringing EasyEffects back from sleep.

EasyEffects relies on PipeWire broadcasting added/removed devices. For example when the user changes its default device Pipewire broadcasts this change to all the clients. EasyEffects listen to this signal and updates its data objects accordingly. If for some reason the broadcast does not come EasyEffects can stay forever trying to use a device that does not exist anymore.

But based on @rscm pw-dot output I fear that option number 2 is the most likely. The reason is that his pw-dot file shows that EasyEffects was able to link its last filter to the new sound card device. So PipeWire sent a broadcast at some point. But as there is no audio player stream linked to EasyEffects virtual sink our pipeline is in the paused state.

On the other hand @carolfs pw-dot output is very different. There is a spotify stream linked to EasyEffects virtual sink. But no filter or link to the new sound card device. I am not sure why... I can see that the link is stuck in the init state. And PipeWire is the one responsible to put each link in the proper state. So some kind of unrecoverable failure happened when PipeWire was handling the link. But I do not know why...

[bhack]

I have experienced something similar multiple time also device reset I needed to close and reopen easyeffects. Is this connected to upstream https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3831 ?

[wwmm]

Is this connected to upstream https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3831 ?

I am not sure. Both problems happen when the computer sleeps. But the issue at PipeWire's page seems to be more on WirePlumber's side considering that audio seems to be working but just playing to an unexpected device.

[bhack]

In my case closings easy effect the audio still works again with the already opened audio apps.

[wwmm]

In my case closings easy effect the audio still works again with the already opened audio apps.

And how is the output of pw-dot when there is no audio?

[bhack]

I need to capture it when happen again

[bhack]

I've had an external device reset. So using HELVUM to visualize/debug the device is available again with all other devices but then EasyEffects it is only connected to the inputs it was connected without reconnecting to the output device. So it is totally disconnected to any output until I restart EasyEffects

[bhack]

Experimenting instead with I turn off and on the device instead it doesn't connect back to the default output but it stay connected to the fallback device.

[wwmm]

So it is totally disconnected to any output until I restart EasyEffects

EasyEffects only tries to link the filters to its virtual sink monitor ports when it detects that there are active players playing to its virtual sink. Assuming that the player stream is not paused or stopped one possibility is that PipeWire did not emit the signals related to the link state. Or they arrived before the system restored EasyEffects process...

Is there any change if you disable EasyEffects Inactivity Timeout in its preferences window? Without the timeout EasyEffects will never try to remove the links to save CPU power.

[rscm]

Is there any change if you disable EasyEffects Inactivity Timeout in its preferences window? Without the timeout EasyEffects will never try to remove the links to save CPU power.

I tried that... same outcome

[bhack]

**EasyEffects only tries to link the filters to its virtual sink monitor ports when it detects that there are active players playing to its virtual sink. Assuming that the player stream is not paused or stopped one possibility is that PipeWire did not emit the signals related to the link state. Or they arrived before the system restored EasyEffects process...

What I've see instead is that when we turn off and on the device the wpctl status Default node is ok but EasyEffect stay connected to the fallback output. So if we don't have EasyEffect the client correctly use the default node when the device is on.

[wwmm]

Default node is ok but EasyEffect stay connected to the fallback output.

I did not understand. Isn't the default device and the fallback the same? OR are you referring to the "user preferred" device set in an audio client device selection menu?

In any case EasyEffects will only try to switch between devices if the corresponding signal about a new device selection is emitted by PipeWire. One way to know if this signal is coming is running EasyEffects in debug mode in a terminal and paying attention to what is being printed there when the new default device is selected.

[bhack]

I did not understand. Isn't the default device and the fallback the same?

No it is not the same. E.g. I switch off the usb audio device and then when press play on the client it will re-connect easyeffects to the fallback device (e.g. internal audio device). When I power on the usb audio device just after few seconds and I press play on the client easyeffects reconnect to the fallback device.

Instead a client without easyeffects correctly reconnect to the external device when we press play we execute the off and on sequence.

[wwmm]

No it is not the same. E.g. I switch off the usb audio device and then when press play on the client it will re-connect easyeffects to the fallback device (e.g. internal audio device).

I see. I understand what you mean. But from the audio server point of view there isn't a default and a fallback as separated entities. Just a default that is chosen by wireplumber among possible devices based on a priority list and on whether they are available or not. In any case a signal about the default device change should be emitted. And EasyEffects relies on it to update its links.

Is this broken only when the computer wakes from sleep or always? Maybe you are seeing a totally different bug.

[bhack]

Yes I meant my "fallback" terminology it was just used to identify the 2nd device priority in the list.

It is broken also when I simply power off and on the usb device without sleep.

[wwmm]

It is broken also when I simply power off and on the usb device without sleep.

Then something different is causing it. It is better to create a new issue for it attaching EasyEffects debug output when the usb device is switched on/off.

[rscm]

I need to capture it when happen again

could you upload your dot file to help fix the issue? thanks

[bhack]

We are already interacting on a new ticket

[checkinindza]

I have opened an issue (#2898) before considering the same exact problem. What's interesting though, I do not have the same issue on EndeavourOS. That's one difference and the other one is that before I installed it as a flatpak package, now as a AUR package. Don't know if that makes a difference, but I don't have this issue anymore.

Just commenting this if it'll be of any help for anyone.

01:00.1 Audio device [0403]: NVIDIA Corporation GA106 High Definition Audio Controller [10de:228e] (rev a1)
07:00.5 Multimedia controller [0480]: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor [1022:15e2] (rev 01)
07:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller [1022:15e3]

[wwmm]

I have opened an issue (https://github.com/wwmm/easyeffects/issues/2898) before considering the same exact problem. What's interesting though, I do not have the same issue on EndeavourOS. That's one difference and the other one is that before I installed it as a flatpak package, now as a AUR package. Don't know if that makes a difference, but I don't have this issue anymore.

@checkinindza are you talking about #2920 or the "sleep bug" discussed here? Or both?

[checkinindza]

I have opened an issue (#2898) before considering the same exact problem. What's interesting though, I do not have the same issue on EndeavourOS. That's one difference and the other one is that before I installed it as a flatpak package, now as a AUR package. Don't know if that makes a difference, but I don't have this issue anymore.

@checkinindza are you talking about #2920 or the "sleep bug" discussed here? Or both?

Sleep issue to be exact

[wwmm]

Sleep issue to be exact

Hum... As I build my own Arch Linux packages I never had a reason to use the Flatpak package. I wonder if everybody having problems with computer sleep/hibernation is using Flatpak...

[bhack]

Could be this a case like https://github.com/wwmm/easyeffects/issues/2920#issuecomment-1947483103 ?

[checkinindza]

At least on Pop_OS!, I haven’t had any issues between switching to headphones and internal speakers, if I understood your issue correctly. But I had the sleep issue. On EndeavourOS I don’t have the sleep issue, but haven’t tested out switching yet though.

[bhack]

Can you check with wpctl status what is the sink device with * annotation before and after the sleep?

[checkinindza]

Before sleep

Sinks:
 │  *   59. Family 17h/19h HD Audio Controller Speaker + Headphones [vol: 1.50]
 │      62. Easy Effects Sink                   [vol: 1.00]

After sleep

 ├─ Sinks:
 │      62. Easy Effects Sink                   [vol: 1.00]
 │  *   89. Family 17h/19h HD Audio Controller Speaker + Headphones [vol: 1.50]

[bhack]

Can you check the received log events before sleep and after resume from sleep with https://github.com/wwmm/easyeffects/issues/2920#issuecomment-1946380565 ?

I am curious to see if you are receiving a new default sink event on resume

[wwmm]

Before sleep

Sinks:
 │  *   59. Family 17h/19h HD Audio Controller Speaker + Headphones [vol: 1.50]
 │      62. Easy Effects Sink                   [vol: 1.00]

After sleep

 ├─ Sinks:
 │      62. Easy Effects Sink                   [vol: 1.00]
 │  *   89. Family 17h/19h HD Audio Controller Speaker + Headphones [vol: 1.50]

@checkinindza So the "sleep bug" does not happen on your computer even if the device was recreated during the process... Interesting... I think that the idea that Flatpak is somehow related is getting stronger...

[wwmm]

I think that the idea that Flatpak is somehow related is getting stronger...

And it could explain why PulseEffects suffered from the same issue in some users setups even having a totally different code and working in a very different audio server...

[carolfs]

I've tried to run EasyEffects in a distrobox rather than Flatpak. The bug is still there, but I can just close EE and the sound comes back. No need to run easyeffects -q.

[bhack]

@checkinindza So the "sleep bug" does not happen on your computer even if the device was recreated during the process... Interesting... I think that the idea that Flatpak is somehow related is getting stronger...

I think we cannot claim this we need to see what happened in the log up until sleep. As it could be just that the sink was removed and finalized and on resume no new default event was generated.

[wwmm]

As it could be just that the sink was removed and finalized and on resume no new default event was generated.

Based on some of the logs above the "sleep bug" does not depend on the default device signal. In some cases it happened even when EE made the link to the correct output device. These are independent problems that may happen in the same time window.