Revamped API - #111
Conversation
… require Send too)
Signed-off-by: Nathan Graule <solarliner@gmail.com>
SolarLiner
added
meta
Signed-off-by: Nathan Graule <solarliner@gmail.com>
Signed-off-by: Nathan Graule <solarliner@gmail.com> # Conflicts: # Cargo.lock # Cargo.toml # src/backends/alsa/stream.rs # src/backends/pipewire/stream.rs
…dio unit + prelude modules + warnings fix
…omatically register Self as an available type to look up
9049442 to
7135dc7
Compare
…tions also add example choosing a specific input device
b7a21a7 to
c47abeb
Compare
|
@Be-ing, @mbernat @strohel sorry for the ping but I thought you might be interested in seeing this. This new API has now matured a little bit, and I have successfully implemented both a CoreAudio and WASAPI backend for it. I believe it is both better ergonomics, the It's a significant shift in the API, so it will break everything. I'm open to feedback and suggestions! |
…macOS-only methods
| let Some(flow) = bitflags_match!(device_type, { | ||
| DeviceType::INPUT => Some(Audio::eCapture), | ||
| DeviceType::OUTPUT => Some(Audio::eRender), | ||
| _ => None, | ||
| }) else { | ||
| return Ok(None); | ||
| }; |
There was a problem hiding this comment.
Hi, I currently cannot run the sine-wave example, because ^this doesn't match on the requested DeviceType::OUTPUT | DeviceType::PHYSICAL (it lands in the wildcard branch and returns Ok(None)). I just discovered interflow and thus know absolutely nothing about it yet, so I can't judge whether it is the example or the platform impl that is wrong, but I know a little bit about WASAPI, and I don't think it has a notion of "physical" devices. E.g. my USB audio interface is recognized as a single 12 channel device by ASIO, but 6 Stereo devices by WASAPI. Hope this helps!
There was a problem hiding this comment.
"Physical" is a device connected to physical speakers, as opposed to "virtual" devices which can be output monitors, or specific applications' output. So yes, it is correct that interflow lists your sound card's I/O as stereo pairs, even though there is only one physical sound card, because that's what WASAPI advertises, somewhat confusingly. An ASIO backend will correctly report a single device, with multichannel I/O.
The code indeed has a bug here, I misunderstood what the match macro does with bit flags. I'll need to change that; but that being said, I also have a USB audio interface and I've tested the WASAPI backend with it, it works correctly.
There was a problem hiding this comment.
Oops, I had assumed it was physical as opposed to "logical" instead. My bad. But then I have to ask: Why care about this difference? And how does the platform even know whether a given driver represents a physical or virtual device?
There was a problem hiding this comment.
On most platforms the query for stuff like application output signals is different from asking for actual devices, so the distinction will be made there. For other platforms it might be more complicated, and I guess there might also be confusion between virtual device drivers (e.g., VoiceMeeter on Windows, or Black Hole on macOS) that will appear as "physical" devices. Maybe better naming is required here.
There was a problem hiding this comment.
Welp, looks like I had the wrong idea again then, because I was indeed thinking of virtual device drivers 😅 But I think I get it now. This is conceptually exclusive to platforms which have a central sound server, right? (My expertise is primarily with ASIO, which doesn't)
There was a problem hiding this comment.
Not necessarily, as long as the server backend has metadata to distinguish port types (e.g., PipeWire tells you if the port is from a "physical" device, or the output signal from another node or application). I don't think there's a way for ASIO to have "virtual" devices, or connections between applications, so in that case you'll only get "physical" devices.
4 participants
Supersedes #31.
Description
This PR changes the design around audio devices, streams and callbacks. Instead of separate input and output traits and types, they are now fused into one, as this is a runtime distinction and not a compile-time one.
This PR will also remove bitflags for choosing which inputs/outputs are opened, and instead opts for the more natural choice of specifying a number of audio channels.
Closes #29.
Type of Change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests you added or ran to verify your changes. Provide instructions so we can reproduce. Try to run
on as many audio drivers as you can get your hands on.
Checklist:
need to be validated manually (i.e. a new audio driver), use examples that can be run to easily validate them.