Originally posted by darkbasic
View Post
Announcement
Collapse
No announcement yet.
SDL 3.0 Will Now Prefer PipeWire Over PulseAudio
Collapse
X
-
Code:systemctl --user list-units | rg pipewire pipewire-pulse.service pipewire.service pipewire-pulse.socket pipewire.socket​
Unless SDL somehow relies on PulseAudio API and uses Pipewire directly at the same time?
- Likes 1
Comment
-
Originally posted by rmfx View PostSo… 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.
Comment
-
Originally posted by Weasel View PostThen 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.
...
- Likes 4
Comment
-
Originally posted by cend View PostRhythm games would definitely benefit from this, as the genre usually features explicitly tight timings and would benefit from low audio latency.Last edited by caligula; 12 April 2024, 09:26 PM.
- Likes 2
Comment
-
Originally posted by caligula View Post
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.
- Likes 3
Comment
-
Originally posted by darkbasic View PostWhy should it look for pipewire-pulse? That's the pulseaudio compatibility layer, you don't need that if you want to use native pipewire.
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:
Code:If pipewire-pulse: Use pipewire API elif pulseaudio works: Use pulseaudio API else: Use pipewire API
Last edited by airminer; 13 April 2024, 02:05 AM.
- Likes 7
Comment
-
Originally posted by SilverBird775 View PostReal 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.
- Likes 3
Comment
-
Originally posted by fallingcats View PostThat'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.
- Likes 4
Comment
Comment