-
Notifications
You must be signed in to change notification settings - Fork 158
Add format to AudioDataCopyToOptions to convert #349
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
Conversation
Fixes #232. Also, I've added validation of copyTo options to both allocationSize() and copyTo() (previously only the latter), such that any call to allocationSize() that succeeds should also succeed with copyTo().
@padenot please give priority to reviewing the API shape / behavior, as we'd like to launch with this in Chrome v1. In a follow up, I imagine we'll want to say more about how conversion takes place. Looking at Chrome's impl for just the float32 conversion (e.g. here's planaru8 to float32), this seems like a potentially dense matrix of info. Lets chat about to spec this consicely. |
Editors Call: Paul to take a closer look, generally looks right. Follow up PR for conversion can simply use min/max/zero from AudioSampleFormat paramaterized steps. |
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.
Looks good overall. I'm not sure if only mandating a single conversion is worth it, it's simple enough to do all of them.
We need to follow up with less hand-wavy conversion steps. As mentioned, the min/max/bias are already specced so there's not a lot to do.
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.
Thanks!
Re: support mandate, Chrome's support is currently limited to just conversion to f32 planar. Basically a detail of the longstanding audio pipeline in chrome, which does all mixing in f32. I agree we could implement more. Do you think conversions to other formats beyond f32 planar will useful?
Lets go ahead and land this and follow up in #352 |
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
SHA: 9dc3359 Reason: push, by @chcunningham Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Fixes #232.
Also, I've added validation of copyTo options to both allocationSize() and
copyTo() (previously only the latter), such that any call to
allocationSize() that succeeds should also succeed with copyTo().
Preview | Diff