SDL 3.0 Will Now Prefer PipeWire Over PulseAudio

[shmerl]

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'm confused with the same thing.

[shmerl]

systemctl --user list-units | rg pipewire
  pipewire-pulse.service
  pipewire.service
  pipewire-pulse.socket
  pipewire.socket​

So why bother with pipewire-pulse? Check for pipewire service itself.

Unless SDL somehow relies on PulseAudio API and uses Pipewire directly at the same time?

[SpyroRyder]

So… it doesn’t use pipewire native basically, it just targets pipewire-pulse in the case of a system that has both pw and pulse…
I think it’s time to default to pipewire native.

But thats what its doing. We cant yet trust that all distros are running pipewire so it checks to see if you are by if you are running normal pulseaudio or pipewire-pulse. If you have pipewire pulse you have pipewire and can safely switch to it

[mxan]

Then PipeWire is dead, since a lot of apps only have PulseAudio backend. Closed source apps (and games) that won't even receive updates anymore. So please don't fucking start with having them updated.

This is literally proof why Linux userland always fails in comparison to Windows.

...

That's a lot of anger over a nothingburger. Pipewire-pulse might stop being installed by default sometime 10 years in the future but guess what? It's open source. You can just install it yourself and boom, PulseAudio support is back. PulseAudio itself is still maintained too, it had an update just 3 months ago.

[caligula]

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

Pro gamers require extreme low latencies. You should at least have eevdf scheduler and rt patches for the kernel. One usb device per usb host, max. Most expensive two stick ddr5 kit with low latency. I'd also use a bolt/lto/pgo kernel with most drivers disabled. You don't need other than killer nic, nvme, amdgpu, usb, hid, and scarlet audio interface support for gaming. Ext4 for disk. Basic TCP/IP stack. No swap or initramfs. No desktop environment. Plain Wayland with explicit sync.

[cend]

Pro gamers require extreme low latencies. You should at least have eevdf scheduler and rt patches for the kernel. One usb device per usb host, max. Most expensive two stick ddr5 kit with low latency. I'd also use a bolt/lto/pgo kernel with most drivers disabled. You don't need other than killer nic, nvme, amdgpu, usb, hid, and scarlet audio interface support for gaming. Ext4 for disk. Basic TCP/IP stack. No swap or initramfs. No desktop environment. Plain Wayland with explicit sync.

Such a setup can be extremely costly for most users. There are far more mediocre players than eSports competitors and the default setup is already good enough for the common.

[airminer]

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.

AFAIU it looks for pipewire-pulse, because some distros eg. Ubuntu (used to?) configure pipewire for desktop/video streaming, while using pulseaudio for the audio stack.

If you check for the `pipewire` service, you will switch over to pipewire, even if that's not what the distro intended.

If `pipewire-pulse` is running, the pulseaudio API is backed by pipewire, so SDL switches over to the native pipewire audio backend, skipping a layer of emulation.

SDL's default audio backend logic on Linux is now:

If pipewire-pulse:
  Use pipewire API
elif pulseaudio works:
  Use pulseaudio API
else:
  Use pipewire API

[fallingcats]

Real tragedy and a huge loss of audiophile investments is the cancelation of the PCI slots. It seems USB devices appeared out of desperation since USB is the only candidate to survive PCI-E.

The random reader who wonders how it is even a problem please pass by, enjoy your monthly upgrade routines. Audiophile equipment never gets old or expire, it only wears out. And it's worth half a kingdom plus kidney.

That's not a tragedy, that's just common sense. Even a 1x PCIe 5.0 lane is 4GB/s. Most audio use cases can happily coast along on an effective 40MB/s that USB 2.0 provides. It would just be a waste of a PCIe slot really. I'm not doubting that putting a DAC on its own USB host port has advantages over being attached to through an (sometimes internal) hub, but that about it.

[byteabit]

Or just output in digital audio format (HDMI over gpu or optical SPDIF from motherboard).

[SilverBird775]

That's not a tragedy, that's just common sense. Even a 1x PCIe 5.0 lane is 4GB/s. Most audio use cases can happily coast along on an effective 40MB/s that USB 2.0 provides. It would just be a waste of a PCIe slot really. I'm not doubting that putting a DAC on its own USB host port has advantages over being attached to through an (sometimes internal) hub, but that about it.

Audio is about latency, dear sir, latency. Quality of audio depends on how quick you can react on command signals, data bandwidth is secondary and never an issue. Modern SOC build-in audio have the luxury of the hacked-in-chip dedicated control lines. Those codecs are not your typical PCI-E or USB device. And because you (like most users) are satisfied with the hacked solution you are missing the whole picture. PCI slots have a dedicated control lines, PCI-E does not. PCI delivers commands in real time, PCI-E does not. For an audio (Real-Time processing) the parallel connection is always the only right choice because you cannot catch up the time by a pure bandwidth.