PipeWire 1.0 RC2 Released With Fixes, Improved Rate Switching

[Type44Q]

"As a nerd, I love the PipeWire logo!"

True nerds don't even notice logos, much less care about them.

Just saying.

[carewolf]

So when I get clicking audio now in teams, is it because teams updated and broke, or because my distro switched to pirewire?

[Almindor]

It's because pipewire tries to open the device in the highest bitdepth and your driver says it can do 32 bits but then produces garbage. Pulseaudio opens the device in 16 bits and that likely works.

It requires a kernel driver tweak for your hardware model. You can meanwhile work around it with a software tweak. To do this, force 16 bits on the camera node, see here: https://pipewire.pages.freedesktop.o...ode-properties You want `["audio.format"] = "S16LE"`.

Thanks for this, I'll try it out.
I'm curious why pulse doesn't follow the same logic then? Or is pulseaudio just doing 16bits on everything coz <reasons>?

[Weasel]

Thanks for this, I'll try it out.
I'm curious why pulse doesn't follow the same logic then? Or is pulseaudio just doing 16bits on everything coz <reasons>?

Because 16-bit is the most compatible and you definitely don't need more than that.

There's no way in hell your noise floor when recording is less than -80dB. Simply no way. So recording in anything higher is beyond pointless.

Converting it to higher bit depth after-the-fact is fine, if you're going to do extra processing (e.g. noise removal) before remastering it back to 16-bit, of course. But recording at higher than 16-bit is simply pointless, processing it isn't.

[RealNC]

Because 16-bit is the most compatible and you definitely don't need more than that.

There's no way in hell your noise floor when recording is less than -80dB. Simply no way. So recording in anything higher is beyond pointless.

Converting it to higher bit depth after-the-fact is fine, if you're going to do extra processing (e.g. noise removal) before remastering it back to 16-bit, of course. But recording at higher than 16-bit is simply pointless, processing it isn't.

It's useful for mixing. Theoretically. In truth, I don't think anyone can pick up an audible difference between mixing several 16-bit sources into a 32-bit stream that is sent directly as-is to the device ("good") or to a 32-bit stream that is then reduced to 16-bit and sent to the device afterwards ("bad.") And the reduction step is probably even going to happen with pipewire too, but to 24-bit, since most devices can't handle float samples. They accept 32-bit integer samples and the hardware will then truncate 32 to 24.

In the end, I don't think it matters.

[Weasel]

It's useful for mixing. Theoretically. In truth, I don't think anyone can pick up an audible difference between mixing several 16-bit sources into a 32-bit stream that is sent directly as-is to the device ("good") or to a 32-bit stream that is then reduced to 16-bit and sent to the device afterwards ("bad.") And the reduction step is probably even going to happen with pipewire too, but to 24-bit, since most devices can't handle float samples. They accept 32-bit integer samples and the hardware will then truncate 32 to 24.

In the end, I don't think it matters.

Like I said you can do mixing/processing in 32-bits (float) and you should do that in my opinion (mostly to avoid having to deal with clipping until the end). That doesn't mean the recording source has to be 32 bits float. Conversion is simply done on the fly.

tl;dr 16-bit is not enough during mixing, but for the recorded source is.

[mppix]

Thanks for this, I'll try it out.
I'm curious why pulse doesn't follow the same logic then? Or is pulseaudio just doing 16bits on everything coz <reasons>?

Pipewire simply tries to enable the best quality that every device advertises in its driver.
In pulseaudio times, 16bit was the best quality available going beyond it was not really "needed". This was also not high priority because they were busy fixing all the other driver issues.

Pipewire replaces also both pulsaudio and jack. For jack applications, this matters: 24bit or better recording is the standard today.

Also contrary to some statements here, bits do not directly map to SNR or vice versa.

[andrei_me]

Just logged in to say thanks to everyone who commented here with configs fixes and/or shared general knowledge in audio stuff 👏