Regression: version 8.1.3-1.1 forces 48kHz resampling on PipeWire despite allowed-rates config

[octop-linux]

EasyEffects Version

8.1.3-1.1 (Problem exists here; verified fixed on 8.1.2-1)

What package are you using?

Arch (easyeffects)

Distribution

CachyOS (Arch Linux)

Describe the bug

After updating to version 8.1.3-1.1, the EasyEffects virtual sink is no longer following the PipeWire graph rate. Even with default.clock.allowed-rates configured in PipeWire to include 44100, and the source (Firefox) playing at 44100, EasyEffects forces the output hardware (ALL USB DACs) to resample to always 48000Hz.

When EasyEffects is removed from the chain or when downgraded to 8.1.2-1, bit-perfect switching works correctly and the hardware matches the source rate (44100Hz).

Expected Behavior

The EasyEffects sink should be passive and follow the hardware rate requested by the source, allowing for bit-perfect playback without forced resampling to 48kHz.

Debug Log

"Currently on 8.1.2 where the issue is not present. If needed, I can upgrade back to 8.1.3 to generate a log, but the pw-top mismatch in the attached screenshot clearly shows the regression in the hardware rate management."

Additional Information

System Details:

• DAC: CX31993 (USB)

PipeWire Configuration:
I am using a global allowed-rates configuration:
default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 352800 384000 ]

Observations:
In version 8.1.3-1.1, the EasyEffects virtual sink seems to prevent the ALSA node from switching to the source rate, locking it at 48kHz. This occurs even when no other streams are active. Reverting to 8.1.2-1 restores the expected bit-perfect switching behavior.

[wwmm]

Hum... Some things changed on PipeWire's side and in order to solve #4914 and #4860 we had to stop using passive links. That is probably the reason why EasyEffects sink is stuck in the same sampling rate. I am not sure if it is possible to fix that without bringing the other issues back.

[octop-linux]

Hum... Some things changed on PipeWire's side and in order to solve #4914 and #4860 we had to stop using passive links. That is probably the reason why EasyEffects sink is stuck in the same sampling rate. I am not sure if it is possible to fix that without bringing the other issues back.

"Thanks for the quick reply! The loss of passive links is a significant regression for bit-perfect audio users. Since 8.1.3, it is impossible to have the DAC follow the source sample rate (e.g., 44.1kHz) while EasyEffects is active, as the sink becomes 'sticky' at 48kHz. I will open an issue with PipeWire to see if there is a way to support both use cases."

[octop-linux]

"To provide more context, I’ve done some A/B testing on Arch/CachyOS (PipeWire 1.6.0 / WirePlumber 0.5.13) and found that the removal of passive links has created a 'firewall' for sample rate propagation:

When EasyEffects is OFF: Bit-perfect switching works perfectly (Firefox 44.1k → DAC 44.1k). This confirms the hardware and PipeWire global config are correct.

When EasyEffects 8.1.3 is ON (Default): The sink acts as an active driver, locking the graph at 48k. Firefox is forced to resample immediately.

When forcing node.passive = true via WirePlumber: Firefox and EasyEffects correctly align at 44.1k, but the rate-change request fails to reach the hardware, which remains stuck at 48k.

It seems that without the node.passive property at the application level, PipeWire refuses to propagate the clock change through the virtual sink to the ALSA output. For now, I’ve downgraded to 8.1.2 to restore bit-perfect functionality. I hope this helps in considering a potential 'HiFi' toggle or a way to allow passive links for users who don't experience the latency/popping issues."

[Ded4lus]

Can confirm regression reported by @octop-linux . This is a real issue for HI-FI usage.
@octop-linux and @wwnn : Was this reported to Pipewire ? If yes, could you please link the bug report here ?

[wwmm]

Was this reported to Pipewire ? If yes, could you please link the bug report here ?

I talked to its developer today in PipeWire's matrix channel. He said he would try to take a look at this tomorrow. But the thing is that this isn't technically a bug. PipeWire is handling some things in a different way to fix inconsistencies somewhere else and it just happens that passive links are not allowing some nodes to be activated when easyeffects expects it to happen.

Using passive links makes the dynamic sampling rate switching work. But right now they break our test signal generator, Kodi when used with EasyEffects and our microphone monitor feature. I am still investigating if it is possible to fix them without having to use active links.

[Ded4lus]

Thanks for the reply, and for the effort.

[octop-linux]

Was this reported to Pipewire ? If yes, could you please link the bug report here ?

I talked to its developer today in PipeWire's matrix channel. He said he would try to take a look at this tomorrow. But the thing is that this isn't technically a bug. PipeWire is handling some things in a different way to fix inconsistencies somewhere else and it just happens that passive links are not allowing some nodes to be activated when easyeffects expects it to happen.

Using passive links makes the dynamic sampling rate switching work. But right now they break our test signal generator, Kodi when used with EasyEffects and our microphone monitor feature. I am still investigating if it is possible to fix them without having to use active links.

Here is the link to the PipeWire report: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues?sort=created_date&state=opened&first_page_size=20&show=eyJpaWQiOiI1MTYzIiwiZnVsbF9wYXRoIjoicGlwZXdpcmUvcGlwZXdpcmUiLCJpZCI6MTQ4MzQzfQ%3D%3D

@wwmm, thank you for investigating this! It's clear that features like the signal generator and Kodi need 'Active' behavior to stay awake. However, for music listeners using Firefox/MPD/Strawberry with a bit-perfect DAC, those 'Active' links act as a 48kHz lock.

If a universal fix for both passive and active links is too difficult, would you consider a 'HiFi Mode' toggle in the settings? This could simply switch EasyEffects back to passive links for users who don't use the Mic Monitor or Signal Generator, but need bit-perfect switching.

[wwmm]

It took much more effort than I think it should but I was able to find a way to make everything work. Or at least it works on my computer 😄 . EasyEffects 8.1.4 released. Let me know how things go for you.

The solution itself is simple. Using passive links in all filters except the first in the pipeline. Somehow this allows the dynamic sampling rate switching to trigger while also making Kodi and our test signal generator to output audio.

If that is the intended behavior they will need to do some serious documentation update. It was way to hard to figure this out...

[Ded4lus]

@wwmm : Nicely done, seems to work like a charm, I just compiled 8.1.4 from source on Arch based CachyOS.

[Ded4lus]

@wwmm : Sorry for the double post, it's for the ping. I might have spoken a bit quickly, I think the fix have introduced some weird comportment (samplerate switch on alsa output doesn't append on the fly). Need some testing.

I just compared to 8.1.2, and there is definitely something preventing on the fly samplerate switching. On 8.1.2, when you switch between tracks with different samplerate, alsa output switches samplerate instantly. Here I have to switch off an on effects (parametric equalizer in my case) for samplerate switch to be effective on alsa output. And, sometimes, if you stop (not pause, stop) the track with effects active, you disable effects, there is no more alsa output on dac when you launch a track with effects disabled. It doesn't happen if you disable effects when the track is still playing though. I'll make a video in a bit to illustrate if it's not clear.

[Ded4lus]

Post-8.1.2-samplerate-issue.mp4

[Ded4lus]

@wwmm : On the video, I first illustrate the switch not being applied on the fly unless you turn off and on effects, at the end the fact that turning off effects after stopping a track disables alsa output until you turn back on effects. Both issues are not present in 8.1.2.

[EDIT] : And, I noticed that easyeffects_sink is always 48000 Hz (on 41000 and 96000 example tracks), so there might be resampling, which is what we try to avoid. In 8.1.2, easyeffects sink has the same samplerate than source (input) and output.

[octop-linux]

@wwmm, I am experiencing the same results as @Ded4lus on version 8.1.4. While this version successfully allows the ALSA hardware to switch rates (unlike 8.1.3), the easyeffects_sink itself remains stuck at 48kHz regardless of the source.

This creates what I’d call a 'resampling sandwich.' For example, if I play a 96kHz file, Firefox sends 96k, but EasyEffects resamples it to 48k for processing because of that first active filter. PipeWire then resamples it back to 96k to match the DAC. We see the correct rate on the hardware, but we've lost the high-fidelity benefits of the source material in the middle of the chain.

In 8.1.2, the entire chain would switch in unison to 96kHz. Since it is clearly difficult to find a single logic that satisfies both the stability fixes (Kodi/Mic Monitor) and bit-perfect switching, would you consider adding a 'Use Passive Pipeline' toggle in the settings?

Toggle ON (HiFi Mode): Reverts to the 8.1.2 logic (entirely passive). Users who prioritize bit-perfection can opt-in and accept the risk of the bugs mentioned in #4914.

Toggle OFF (Default): Uses the new Hybrid/Active logic for general stability.

This would allow us to restore the 8.1.2 behavior for critical listening without sacrificing the progress you've made for the rest of the user base.

[wwmm]

As things are right now the kind of test you did in your video is not going to work. You have to wait enough for easyeffects to unlink it's filters before starting a new track that has a different sampling rate. It is what I did when I tested with mpv yesterday. As long as the sink is allowed to enter the suspended state it switches to the new sampling rate.

That instantaneous change is only possible with passive links in all filters. But I am not fond of the idea of having a mode that causes broken features by design. Sooner or later there will be users wanting to have both things at the same time and it just d9es not seem possible right now.