[bug] EasyEffects sink no longer follows sample rate assigned in pipewire.conf after Pipewire 1.4.0 update [Pipewire regression]

[craftfever]

EasyEffects Version

7.2.3

What package are you using?

Arch (easyeffects)

Distribution

Arch Linux, kernel ver 6.13.7

Describe the bug

default.clock.rate          = 192000
default.clock.allowed-rates = [ 192000 ]

Despite changing default.clock.rate and default.clock.allowed-rates, for example, to 192000 hz, EasyEffercts/easyeffcts_sink always stays at 48000 hz.

Expected Behavior

Easy Effects Sink runs at sample rate that assigned in Pipewire config.

Debug Log

No response

Additional Information

pactl list sinks short
68      alsa_output.pci-0000_00_1b.0.analog-stereo      PipeWire        s32le 2ch 192000Hz      RUNNING
799     easyeffects_sink        PipeWire        float32le 2ch 48000Hz   RUNNING

I tried downgrade to Pipewire ver. 1.2.7 and it worked as excepted, EasyEffects runs at 192khz, but with ver. 1.4.x, EasyEffects always reporting 48khz, and pactl or pw-top showing the same - sink locked at 48khz.

P. S. I've compiled and installed easyeffects-git with fixed client-rt.conf/client.conf problem, but sample rate issue remains here too.

[wwmm]

I tried downgrade to Pipewire ver. 1.2.7 and it worked as excepted, EasyEffects runs at 192khz, but with ver. 1.4.x, EasyEffects always reporting 48khz, and pactl or pw-top showing the same - sink locked at 48khz.

Hum... I did not notice that PipeWire's update had broken this. It really feels like a PipeWire's regression. This is something that is handled entirely on its side. Unless that now they require the client to do something about this.

[wwmm]

I did some tests while looking at pw-top output and the soundcard does change automatically to the correct sampling rate. It seems that the latest PipeWire release just does not update the null sink rate value to the one that is actually being used and shows 48 kHz forever.

In EasyEffects we show the rate of our null sink device because this was always shown to have the same value as the one in the soundcard. At first sight things seems to be working as far as the dynamic sampling rate switching is concerned. There shouldn't be a reason for PipeWire to be doing resampling for the null-sink.

[wwmm]

It seems to me that the property we use to get the rate value is not initialized by PipeWire anymore... They probably changed how this information is supposed to be obtained...

[wwmm]

Even if things are a little different now the fact PipeWire does not update the rate property for null-sink devices remains... I wonder if this is intended...

[wwmm]

I've updated our master branch with a workaround for this. Try to install the AUR package. It builds from our master branch.

I am not sure if PipeWire has a new bug or if this is the new intended behavior. But at the end of the day the rate it sets for the plugins matches the one it sets to the hardware. So now we just show it instead of the one reported by the null-sink. That for some reasons PipeWire is not updating anymore.

[craftfever]

I've updated our master branch with a workaround for this. Try to install the AUR package. It builds from our master branch.

I am not sure if PipeWire has a new bug or if this is the new intended behavior. But at the end of the day the rate it sets for the plugins matches the one it sets to the hardware. So now we just show it instead of the one reported by the null-sink. That for some reasons PipeWire is not updating anymore.

Pipewire issue tracker not avaiable right now due to infrastracture transition, maybe it's better file a bug to them, but I'm aware, that EasyEffects internally works at target configured sampling rate, so thank you, problem just with indication and internal incorrect reporting of SR at Pipewire side. Exactly same thing happens with JamesDSP - Pipewire regression.

[craftfever]

Unfortunately, problem goes much further,than just incorrect displaying of sampling rate value. It's literally incorrect reporting and some clients that decides doing resampling for itself, just set target SR to incorrectly reported 48khz really involving double resampling. As example, Telegram, that output audio through OpenAL API, which routing then to Pipewire:

Another example is Chromium, outputing through PulseAudio API and it's fine:

So, it's a serious regeression in Pipewire 1.4.

And, when downgrading to Pipewire 1.2.7, new easyeffects-git, compiled with newest workarounds for 1.4, with 1.2.7 shows zero sampling rate value =)

[wwmm]

As example, Telegram, that output audio through OpenAL API, which routing then to Pipewire:

I do not think there is actually resampling in place. The reason is that the filters that are right after that null-sink are receiving from pipewire the same sampling rate that is on the soundcard. It says that the null-sink is always at 48 kHz but if that were really the case the buffers it sends to ours filters should be always 48 kHz too. But that is not happening.

And, when downgrading to Pipewire 1.2.7, new easyeffects-git, compiled with newest workarounds for 1.4, with 1.2.7 shows zero sampling rate value =)

Hum... It is possible that the workaround makes the value equal to zero on older PipeWire versions. A little unexpected but I can't say is should be impossible.

[VladimirPomogaev]

Unfortunately, I have to admit that I have encountered the same problem.

[craftfever]

As example, Telegram, that output audio through OpenAL API, which routing then to Pipewire:

I do not think there is actually resampling in place. The reason is that the filters that are right after that null-sink are receiving from pipewire the same sampling rate that is on the soundcard. It says that the null-sink is always at 48 kHz but if that were really the case the buffers it sends to ours filters should be always 48 kHz too. But that is not happening.

It's not about null-sink/easyeffects, where no unwanted audio alteration occured, no, I'm talking about different case, that I found through researching bug about incorrect SR reporting by PW1.4. Some audio clients, that decides doing their own resampling to target sample rate, selects incorrent value due to bug in Pipewire and resampling into 48khz, instead of targer SR (192khz in this case), so double resampling (44.1-48-192) ocured, instead of 44.1-192, regardless of easyeffects. I showed it on screenshot of pw-top above. For example, Telegram:

[I][22:21:12.767365] pw.node      | [     impl-node.c: 1266 check_properties()] (telegram-desktop-0) latency:0/0 -> 4096/192000
[I][22:21:12.767387] pw.node      | [     impl-node.c: 1297 check_properties()] (telegram-desktop-0) rate:0/0 -> 1/48000

We have incorrect sample rate setting for clent. (despite of correct latency value, which not propose correct rate) This happens with particular apps, Chromium resampling to correct target SR, for example.

And, when downgrading to Pipewire 1.2.7, new easyeffects-git, compiled with newest workarounds for 1.4, with 1.2.7 shows zero sampling rate value =)

Hum... It is possible that the workaround makes the value equal to zero on older PipeWire versions. A little unexpected but I can't say is should be impossible.

It's really better to revert SR value definition to original state. Obviously, it's Pipewire's notable regerssion, I'll file a bug to them, but its tracker is unavaliable for now due to platform transition. It's a shane, that RedHat, which using freedesktop's products for their own profit, didn't properly maintained server infrastacture for FreeDesktop and their apps at a time of financial problems.

[wwmm]

It's really better to revert SR value definition to original state. Obviously, it's Pipewire's notable regerssion, I'll file a bug to them, but its tracker is unavaliable for now due to platform transition. It's a shane, that RedHat, which using freedesktop's products for their own profit, didn't properly maintained server infrastacture for FreeDesktop and their apps at a time of financial problems.

I see. I think we can wait for the fix on PipeWire side before reverting. As things are right now the label is useless on the latest PipeWire release and that is the one we have on Arch Linux. People on other distributions may already have to hold EasyEffects updates for other reasons.

[craftfever]

It's really better to revert SR value definition to original state. Obviously, it's Pipewire's notable regerssion, I'll file a bug to them, but its tracker is unavaliable for now due to platform transition. It's a shane, that RedHat, which using freedesktop's products for their own profit, didn't properly maintained server infrastacture for FreeDesktop and their apps at a time of financial problems.

I see. I think we can wait for the fix on PipeWire side before reverting. As things are right now the label is useless on the latest PipeWire release and that is the one we have on Arch Linux. People on other distributions may already have to hold EasyEffects updates for other reasons.

Regression fixed with this commit in the master branch, should be in next release :)
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/6f8a814f29cb749eaf8a2ed37fdd67cc9a9b90eb

Further details: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4619

Everything fine with newest pipewire-git and workaround for determining of sampling rate is not necessary anymore.

[wwmm]

Thanks for the information. I've reverted the workaround on our side.