SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

[billyswong]

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?

Currently there are computers that run pipewire but not using it to pipe audio. They can also add additional check, to retry pipewire after pulseaudio fails.

[Ferrum Master]

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

Report what? Hey don't change your api syntax in the Lua scripts?

It is you on your own with your each specific device and modes. Whoever came up with the idea that USB is good for audio must be prosecuted. I wont even touch the last remaining native PCIe devices, those are over ~10 years old already and dead most development nowadays go to wireless BT technologies, that I don't care of.

99.9% people actually don't care for audio as long something garbles out the speakers... even less actually have the ability to not be subjective and actually measure what's going on.

No matter Pulse or Pipe whoever speaks to ALSA, the way it is done is far from optimal and making Linux desktop as viable daily driver for masses, gaming included as gaming is very latency sensitive.

[V1tol]

I am always amused how carefully people read articles. Article says - SDL will search for running instance of pipewire-pulse to decide using native Pipewire. Native Pipewire support was implemented in SDL2 and SDL3 will use it by default. In 99% of cases if you use Pipewire - you have pipewire-pulse and it is a decent Pipewire presence indicator.

[cend]

Report what? Hey don't change your api syntax in the Lua scripts?

It is you on your own with your each specific device and modes. Whoever came up with the idea that USB is good for audio must be prosecuted. I wont even touch the last remaining native PCIe devices, those are over ~10 years old already and dead most development nowadays go to wireless BT technologies, that I don't care of.

99.9% people actually don't care for audio as long something garbles out the speakers... even less actually have the ability to not be subjective and actually measure what's going on.

No matter Pulse or Pipe whoever speaks to ALSA, the way it is done is far from optimal and making Linux desktop as viable daily driver for masses, gaming included as gaming is very latency sensitive.

The audiophile community is notably filled with myths given the complexities of building an acoustic system, but below that I find it very hard to get really bad when it comes to audio. Just my two cents.

[ssokolow]

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.

I suspect that "If Dbus support or systemd are not available, the standard audio driver order will be used." is the key.

If the standard audio driver order contains something like "Try PulseAudio, then Pipewire", then this change becomes "Try PulseAudio, then Pipewire, unless the PulseAudio support is just an extra layer on top of Pipewire, in which case go direct."

[darkbasic]

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.

I must quote ChrisLane about that:

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?

pipewire-pulse won't be a thing forever. Some people already ceased installing pipewire-alsa and the same will eventually happen for every other compatibility layer.

[reba]

I am always amused how carefully people read articles. Article says - SDL will search for running instance of pipewire-pulse to decide using native Pipewire. Native Pipewire support was implemented in SDL2 and SDL3 will use it by default. In 99% of cases if you use Pipewire - you have pipewire-pulse and it is a decent Pipewire presence indicator.

But pipewire-pulse is not native Pipewire, it is Pulseaudio-API on PipeWire-Service, instead of pulseaudio, which is Pulseaudio-API on Pulseaudio-Service.
Native Pipewire would be Pipewire-API on Pipewire-Service and there are quite many applications supporting this.
Thus, pipewire-pulse is just an application still talking Pulseaudio and being oblivious of the implementing service. It's Pulseaudio for it after all.

[Monsterovich]

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.

Why make native pipewire support when there is a working pipewire-pulse? I don't understand the point of multiplying sound APIs: libpulse/jack is enough on the desktop.

[byteabit]

Why make native pipewire support when there is a working pipewire-pulse?

To simplify the setup for end user (less dependency) and for the programmers too.

[cend]

Why make native pipewire support when there is a working pipewire-pulse? I don't understand the point of multiplying sound APIs: libpulse/jack is enough on the desktop.

SDL is designed for games, and there is one game genre I've mentioned that hates the latency and other issues introduced by PulseAudio. Last time I played osu!(lazer) using the PulseAudio backend it was a very horrible experience.