SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

[phoronix]

Phoronix: SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

For the widely-used SDL hardware/software abstraction layer that is commonly used by cross-platform games, the upcoming SDL 3.0 release now has the logic to be able to prefer using PipeWire directly rather than PulseAudio when successfully detecting the presence of PipeWire...

https://www.phoronix.com/news/SDL-3.0-Prefer-PipeWire

[darkbasic]

Why should it look for pipewire-pulse? That's the pulseaudio compatibility layer, you don't need that if you want to use native pipewire.

[Ferrum Master]

Not sure the about the praising.

But I still think Pipewire is not mature enough for what it intends to be. It lacks normal configuration and information if you experience latency and audio distortion... Same applies to WirePlumber as it now needs different syntax and most guides are not compatible, so it ends up in a headache if you are up to running something more than in build laptop speakers.

On the other hand you are so used to PulseAduio quirks, you know what to tweak as usually those are only two files + basic ALSA settings.

[mxan]

So it will use pipewire’s API or it will just use use the PulseAudio compatibility layer? Seems like the latter, given it looks for pipewire-pulse…

[mxan]

It lacks normal configuration and information if you experience latency and audio distortion... Same applies to WirePlumber as it now needs different syntax and most guides are not compatible, so it ends up in a headache if you are up to running something more than in build laptop speakers.

Have you reported any bugs upstream and asked for that configuration you need to be added?

[cend]

Rhythm games would definitely benefit from this, as the genre usually features explicitly tight timings and would benefit from low audio latency.

Why should it look for pipewire-pulse? That's the pulseaudio compatibility layer, you don't need that if you want to use native pipewire.

Most non-professional desktop apps and desktop environments use the PulseAudio API for audio support, so checking for pipewire-pulse is a pretty decent audio setup correctness check. Usage of the PulseAudio API for consumer apps is recommended by PipeWire developers even when PipeWire has rendered the PulseAudio daemon obsolete.

[cend]

So it will use pipewire’s API or it will just use use the PulseAudio compatibility layer? Seems like the latter, given it looks for pipewire-pulse…

PulseAudio daemon and pipewire-pulse are mutually exclusive.

[byteabit]

On the other hand you are so used to PulseAduio quirks, you know what to tweak as usually those are only two files + basic ALSA settings.

https://xkcd.com/1172/

[ChrisLane]

Why should it look for pipewire-pulse? That's the pulseaudio compatibility layer, you don't need that if you want to use native pipewire.

I thought this was strange too. In the (long distant) scenario where a system may not even have pipewire-pulse, would this fail as it tries to use pulseaudio instead of native pipewire?

[mxan]

PulseAudio daemon and pipewire-pulse are mutually exclusive.

Yes, however PipeWire implements the PulseAudio API, so all apps should “just work” with PipeWire, including SDL. Explicitly searching for PipeWire if it only uses the PulseAudio API makes no sense.