pulse: Lazy prototype loopback implementation#691
pulse: Lazy prototype loopback implementation#691nikp123 wants to merge 1 commit intomozilla:masterfrom
Conversation
|
Yes, this would work well, although it's possible to reuse lots of code we have. You can for example enumerate all devices using either the internal or external API, and pick a monitor device as your input device. The "loopback" feature is WASAPI-only historically because it's somewhat possible to achieve this externally (monitor device are real devices, unlike the WASAPI case where you pass an output device as input device with the flag), but I reckon an alignment would be nice. It's not possible to generally implement this on macOS (outside of Blackhole/Dante Virtual Soundcard/etc.). The current and up to date PulseAudio backend for cubeb is here: https://github.com/mozilla/cubeb-pulse-rs (it has more than a few bug fixes) and is written in Rust. It requires a rust toolchain for compilation, but it's really straightforward to set it up. |
|
@padenot i'll try to get the rust implementation going if that's what's currently used, but yeah i share the same feelings about the current code, this is just hacked together to show how it could be done. EDIT: on a sidenote, despite it "loopback" being a "windows-only" thing I feel like exposing it to a more general interface is mutually beneficial because the end-user (aka application developer) doesnt need to know all these finicky background details to make it work (if you understand where im going with this) |
|
Dropping |
While not an officially advertized feature in the PulseAudio API, all PulseAudio "sink"-s have a "monitor mode" where in any of the audio output devices there's a "loopback" input device which replicates all audio for said output. This allows us to effectively achieve recording any audio output as input within cubeb. This commit is a continuation of said Draft shown in mozilla/cubeb#691 but this time written in Rust. (yes it took me half a year but we're here) As I'm quite inexperienced when it comes to Rust (*especially so when it's demanding code like FFI interfaces*) comments on the code or any improvements that may be done are greatly appreciated. Thanks.
While not an officially advertized feature in the PulseAudio API, all PulseAudio "sink"-s have a "monitor mode" where in any of the audio output devices there's a "loopback" input device which replicates all audio for said output. This allows us to effectively achieve recording any audio output as input within cubeb. This commit is a continuation of said Draft shown in mozilla/cubeb#691 but this time written in Rust. (yes it took me half a year but we're here) As I'm quite inexperienced when it comes to Rust (*especially so when it's demanding code like FFI interfaces*) comments on the code or any improvements that may be done are greatly appreciated. Thanks.
|
Closing this as the priority is on the rust one anyway. |
2 participants
DO NOT MERGE
Context
I've just recently found about this project and I really like the idea of it and thought I'd use it as my main audio library if it manages to do everything I'd want it to be able to do. Unfortunately, loopback mode seems to be WASAPI only despite it being technically possible to pull off (without even user intervention) on both PulseAudio and PipeWire, however these modes are not commonly documented so you may take them with a grain of salt.
What this pull request is?
This is a really hacky implementation of said loopback mode on PulseAudio (ie. monitor mode). Consider it a RFC before I either polish it or you merge it. It is menat to demonstrate possible functionality before anything else.
How does the magic work? ie. how the code works
Basically it's a bit hacky, but the trick is to create a pulseaudio mainloop (ie create a sink) so that we are able to fetch the default sink's name and turn into into a monitor source by appending
.monitorto it's name. Any ideas on simplyfing this code would be appreciated.And of course your opinions/thoughts on this. I, for one, would like to see this functionality enabled in the library (if possible). Thanks.