-
Notifications
You must be signed in to change notification settings - Fork 4
feat: Add ASIO backend #36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: feat/duplex-api
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I got too hasty reviewing this when it's still draft, but I thought I'd do it anyway and you can take the comments into account when you want
5cbf00c to
0b0da73
Compare
b49e376 to
690ae2c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm gonna make a few new changes to the Duplex API branch to remove the DeviceType::Duplex enum since it's useless. I should have done it sooner and it made you do a bunch of extra work for it.
If you haven't rebased onto that branch yet, don't do it just yet; I'll ping you when I'm done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be good now
Hmm okay, I was using that to return the default input and output device since on ASIO that could be a single duplex device. |
305b8d1 to
7817f13
Compare
925fa0d to
375e531
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good now, you have the last suggestion to include and I think we can merge this sooner rather than later –- this way we can iterate over the Duplex API as a whole instead of having to juggle between all those PRs
Yep I agree 👍 was waiting for this to merge before reviewing the duplex api pr. Should be able to finish this off in the next couple of days. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (pending the couple of comments I made).
I think I'll want to make more changes to the general Duplex API (especially the StreamConfig I think I'll separate the input and output channels, it's a little bit of duplication but I think it'll be worth it).
| let device_type = match (is_input, is_output) { | ||
| (true, true) => DeviceType::DUPLEX, | ||
| (true, false) => DeviceType::INPUT, | ||
| (false, true) => DeviceType::OUTPUT, | ||
| // todo | ||
| (false, false) => return Err(AsioError::BackendError(asio::AsioError::NoDrivers)), | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also add DeviceType::PHYSICAL as a property for hardware devices
| let buffer_size = match stream_config.buffer_size_range { | ||
| (Some(min), Some(max)) if min == max => Some(min as i32), | ||
|
|
||
| _ => None, | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think since we can control the exact buffer size, we should go with min or max.min(512) instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand. I thought when min == max then the user has specified a specific buffer size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, however currently you're not respecting the conditions the user has provided in any other case (ex. (None, Some(128) or (Some(256), Some(1024)).
The expression I gate would translate in Rust as min.or(max).unwrap_or(512). But I since saw that the buffer size you pass to asio-sys is actually an Option, so you can remove the .unwrap_or part.
Description
Adds ASIO backend.
Needs #31
Fixes #16
Type of Change
Please delete options that are not relevant.
How Has This Been Tested?
Todo
Checklist:
need to be validated manually (i.e. a new audio driver), use examples that can be run to easily validate them.
Screenshots (if appropriate):
Additional Notes:
Add any additional notes about the PR here.