Pulseeffects: PE should automatically detect sampling rate

[possessedbysatan]

I'm not sure if this is a duplicate of this.

PE only seems to respect the sample rate defined in /etc/pulse/daemon.conf. Even if you play a file with an higher bitrate, let's say, 96KHz, it'll be downsampled to the one defined in pulseaudio's config file.

Steps to reproduce:

1. Open a file with an higher bitrate than the one set in /etc/pulse/daemon.conf (ie. default-sample-rate)
2. Open Pulseeffects. Audio will suffer downsampling. You can verify this by using any DAC that shows the current sampling rate.

I guess Pulseeffects has no way to know if audio is being played at an higher sampling rate.

However, if I set _default-sample-rate_ to an higher sampling rate PE will inded respect that setting. This unfortunately means higher CPU usage.

[wwmm]

Did you set avoid-resampling = yes in /etc/pulse/daemon.conf? Although Pulseaudio has had this feature for a while the bits necessary to make it work with PulseEffects were added only in Pulseaudio 13.

PulseEffects uses the sampling rate Pulseaudio set to the sound card. Without enabling avoid resampling this will always be the default value. If you play something with a different rate Pulseaudio has no option other than resampling.

[wwmm]

Also have in mind that Pulseaudio updates the card rate only when the card is idle. And that PulseEffects waits for 5 seconds before pausing its pipeline once no app is playing audio. This means that if you are playing something at 48 kHz you have to pause or close this audio source and wait for at least 5 seconds before starting another app playing at let's say 96 kHz. If Pulseaudio sees that the card is not idle when a different rate is request it will keep the current card rate and do resampling.

[possessedbysatan]

Here's my daemon.conf. avoid-resampling is set to yes as you said. I'm running Arch Linux and I just confirmed that I have Pulseaudio 13.x.

I wait a little bit when playing songs (or files) with different sampling rates but none of the things you said happen. This is pretty much all I do:

• Open "_HiRes_" file.
• DAC will show file's sample rate and it's okay, that's expected
• Open PulseEffects
• DAC will show the frequency set in default-sample-rate. It doesn't matter if I close the player and open it again, if I play a file with an higher sampling rate or if I wait 5 seconds as you said. As long as I have PulseEffects open, sampling rate is fixed to the value set in default-sample-rate.

If this is not the expected behaviour I would be happy to help with logs or config files. Thank you for the reply.

[possessedbysatan]

Just updated my computer and PulseEffects seems to crash. Pulseaudio runs just fine.

Here's the debug log:
debug.log

[wwmm]

I am also on Arch Linux and so far the new 4.7.3 package is fine. But back to the problem something must be keeping PE pipeline playing. And as a result the card does not go to idle. What is the output of pactl list sinks before you try to play the high sampling rate file? Which player are you using?

[wwmm]

I have downloaded a few high resolution files from this site http://www.2l.no/hires/ and something is definitely not right. When I open a video file at 48 kHz or 44 kHz resampling is avoided as intended. But when using a high resolution file Pulseaudio does not seem to be trying to change our virtual sinks rate. And if that does not happen our pipeline rate won't change. And having the card in the idle state is not making any difference indeed. The question now is why Pulseaudio is behaving differently at higher rates...

[wwmm]

It is almost like Pulseaudio is considering 44 kHz and 48 kHz as the only valid rates to accept automatic switches =/

[wwmm]

I did a few tests looking at Pulseaudio logs on the fly. It tries to reconfigure our sink but for some reason I don't know it assumes that the desired sampling rate is 48 kHz when we play something at a higher rate like 88 kHz or 96 kHz. I will have to ask Pulseaudio developers if that is how it is or if there is a way to set a list of rates that should have automatic reconfiguration supported.

[possessedbysatan]

Thank you for the reply.
That's the exact website from where I'm downloading "_HiRes_" files.

I'm not sure if it's Pulseaudio's fault. I mean, if you try to play one of these "_HiRes_" files Pulseaudio will change the output sampling rate. This only happens when you open PulseEffects.

As far as I know, PulseEffects configures a virtual sink to play the processed audio. I think there could be a way to guess or calculate the sampling rate from one of the input sources and then configure the virtual sink to play audio at said sample rate. Maybe PulseEffects is guessing incorrectly the input sampling rate?

I don't know, to be honest.

[wwmm]

I opened an issue there https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/923.

This kind of configuration change hast to come from Pulseaudio. The reason is that once you load a null sink(virtual device) you can not change its sampling rate from the user side. You would have to destroy it and recreate with new settings. This approach is really problematic. That is why we rely on Pulseaudio automatic sink reconfiguration. And it works with 44.1 kHz and 48 kHz just fine. What I do not understand is why it does not do the same at higher rates.

[wwmm]

Same problem with 32 kHz. I am starting to think that the null sink automatic reconfiguration only works when alternating between the default and the alternate rate...

[possessedbysatan]

You nailed it. Just changed my alternate sample rate to 96kHz (since some of my files have that sampling rate) and PE seems to respect that. It's buggy, though. This is what I did:

• Set sample rate to 44.1kHz, alternate to 96kHz
• Open PulseEffects.
• Play 96kHz file
• PulseEffects indeed starts processing at 96kHz
• Play file with lower sample rate (ie. 44.1/48 kHz)
• All audio that is processed through PulseEffects will have the initial sampling rate (96kHz). That rate is shown in my DAC. At this point it's pretty much obvious that PulseEffects' virtual sink will be stuck with said sample rate.

I guess that's how Pulseaudio works.

[wwmm]

One of the developers answered me. It was a bug in Pulseaudio indeed. avoid-resampling was not being applied to null sinks. Tanu has just made a new Pulseaudio pull request fixing it.

I will keep this issue open until I am able to test Tanu patches and confirm that the issue is gone.

[polygonalenippel]

May I add something? If this is not the proper place, I'll make a new issue.
Considering we are tweaking with sample rates, is it possible to view the device's supported sample rates in PulseEffects, somewhat similar to that drop down menu in Windows? Looking up the specs of my DAC, then editing pulse's config file, then restarting the pulse service -- thereby having to restart each program which made use of this audio pipeline feels complete overkill.
Right now it seems Pulse(Effects) seems to respect only the sample rates which you define in the config, but if you have a DAC which supports a wide range of them, it's a PITA to exploit it properly.

[wwmm]

Considering we are tweaking with sample rates, is it possible to view the device's supported sample rates in PulseEffects, somewhat similar to that drop down menu in Windows?

I am not sure if Pulseaudio has functions that return this information. Maybe if we talk directly to alsa. But even if we get this information we can't not force Pulseaudio to do the rate change. So it would be useless.

Right now it seems Pulse(Effects) seems to respect only the sample rates which you define in the config

We use the one Pulseaudio is using. The problem here is that the current Pulseaudio version is not automatically changing null sinks rate under circumstances it could be doing it. This will change only when Pulseaudio 14 is released.

[polygonalenippel]

I really wish such a feature were to be implemented, for the sake of proper user experience (it really doesn't have to be this hard). Where would be the best place to take this to? @wwmm

[possessedbysatan]

@polygonalenippel

For USB DACs, you can get the available sampling rates with this command:
cat /proc/asound/D10/stream0 | grep -i rate*
My DAC is a Topping D10.

For integrated sound cards, you can use this one as well:
cat /proc/asound/card0/codec#0 | grep rates

Just replace card0 and codec#0 accordingly.

[wwmm]

I really wish such a feature were to be implemented, for the sake of proper user experience (it really doesn't have to be this hard). Where would be the best place to take this to?

@polygonalenippel Even if we read the devices properties inside /proc/asound/ there isn't a way to force Pulseaudio to use a given sampling rate without having to edit its configuration files. The only alternative is the automatic change done by avoid-resampling. So Pulseaudio developers would have to create functions that would allow audio managers to somehow force a sampling rate. In case you want to ask them for this feature you can open an issue here https://gitlab.freedesktop.org/pulseaudio/pulseaudio. But be aware that there aren't many developers working in Pulseaudio. So their hands are already full.

[polygonalenippel]

@possessedbysatan thank you for the suggestion

@wwmm Thank you as well. Given Pulse can check the supported formats, I think there should be an option in Pulse that avoid-resampling can pick the source format if available on the hardware, without being restricted by the alternate-sample-rate (because you can only pick one alternative).

Call it luxury, but given it should be possible, it makes more sense to do so. I will therefore request this on the Gitlab which you mentioned.

[wwmm]

without being restricted by the alternate-sample-rate (because you can only pick one alternative)

@polygonalenippel in general it isn't restricted to the default and alternate rate. This is happening because the the bug described above.

[polygonalenippel]

@wwmm Whoops I did not realize that. My bad.