-
Notifications
You must be signed in to change notification settings - Fork 347
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
24 / 32 bit audio - Support for more SampleFormat
variants and Sample
types
#414
Comments
SampleFormat
variants and Sample
types
Thanks for the issue @julientregoat ! Yeah CPAL's current set of supported
W.r.t 24-bit streams, what layout specifically does the data you have in mind? I imagine it might be a bit trickier to support formats that don't directly correlate with Rust primitive types, but should be doable if there's a good enough use-case. We have to start thinking about packed, unpacked and the justification of the sample data within unpacked formats, and how we might expose this sort of API to the user. There's a nice description of the various possible layouts for 24-bit audio data here. |
Awesome - I actually forked the other day and started adding re: 24 bit, right now I've been working on an AIFF decoder (here's the spec I've been following). They pad the data to fill bytes, justifying it to the left. So 6 bit would look like A couple of ideas come to mind for handling bit rates that don't fit neatly into rust primitives... one is accept a standardized format that seems used by the largest audience, with 1/2/3/4 byte implementations. This is easier, but maybe makes more work than necessary for us and for consumers of the API if the system accepts the audio data as its read. The alternative could be to support 1/2/4 byte buffers in a struct with flags like Again, pretty new to this stuff (both working with |
|
whoops, this is what I meant re: standardized format but had 1/2/4 stuck in my mind from packed constraints. |
I just added proposal that tries to solve this in a generic manner (see draft #690). My goal is to implement all (byte-aligned) sample types used by ASIO, ALSA, etc. Those are (to my current knowledge)
The approach involves the following changes: Migration from This allows to work with more sample types as if they were Rust primitives. This also covers conversions between the types. A possible downside: Introducing
While Introducing With non-power-of-two-types ( Also to consider As this is a breaking change (public facing API changes) we might want to talk about channel management (#367) and a duplex API (#349). Channel layout could be abstracted away by upgrading the I'm not sure if this should be integrated as well (complicating and deferring everything). We can address these at a later stage but that would likely break the API again. Current Status So far I implemented Ergonomics for writing to a The new variants will add a lot more Given that all sample type could be converted into all other types, one could also combine all I think it would be a good idea to allow all three variants:
Oh, and I made Any feedback is welcome. |
Thanks for working on this! One quick note: in the interest of avoiding scope creep and surprising behavior, I don't think cpal should be in the business of automatically converting between sample formats during I/O. I'd like to be able to trust that I'm passing data directly to/getting data directly from the underlying API without any hidden magic. |
I totally agree! This could only happen with "generalization level 2" which should be an opt-in. Even then there will be a way to figure out which sample type can be read/written losslessly. |
hey there! I was interested in using
cpal
for 24 + 32 bit audio. is this currently supported? from the code andSampleFormat
, it looks like this isn't directly supported with 32bit numbers.. I could scale them to -1.0 - 1.0 range but I'm not sure if that's the correct way of doing it or if that would be lossy (edit: yeah seems lossy)let me know, happy to contribute to help make this happen
The text was updated successfully, but these errors were encountered: