PulseAudio support #957
PulseAudio support #957
Conversation
This reduces the exported surface area of each host implementation, and makes the impl_platform_host macro more robust.
This adds support for PulseAudio on hosts with a PA or PipeWire server (the latter via pipewire-pulse). Since the underlying client is async, some amount of bridging has to be done.
|
@colinmarc |
Pipewire and Pulseaudio are completely different protocols. Pulseaudio is the established linux audio server, and Pipewire is the new hotness. This PR implements the Pulseaudio protocol, while the other PR implements the Pipewire protocol. The other useful thing to know is that Pipewire (the server) supports the Pulse protocol as a first-class thing, and that this library has been tested with both audio servers. That means merging this would be enough to handle both cases. The PA server does not support the Pipewire protocol. Finally, this is just my opinion, but I think the Pipewire protocol is also significantly more complicated. |
|
I actually misread the issue and would have removed my comment if you weren't so quick to respond! 🤣
Right, since Pipewire could just interpret cpal through its PulseAudio interface. Thank you for the explanation :) |
Fixes #259.
I finally got around to this after promising to PR it in #259 a year ago. 😅
This is based on colinmarc/pulseaudio-rs#2, which obviously needs to land before this. However, I developed both PRs in parallel. If you're feeling generous and would like to review that as well, I would welcome any feedback.
The first commit is unrelated and a bit opinionated, but it seemed nicer. Let me know if I should move that to a separate PR or just drop it.