-
Notifications
You must be signed in to change notification settings - Fork 72
Description
My use case description got a little lengthy, so I'm putting the question here before I get into it.
Would it be okay to do either of these for the non-standard sample types defined in dasp_sample (like I24):
- add
repr(C)orrepr(transparent), or - also implement
bytemuck::Pod(andZeroable, probably throughderive) behind a feature flag?
I found myself in a situation while working with dasp and cpal in a latency-critical context. While transporting and transforming a signal between multiple threads, it would be convenient for me to convert a slice of samples to a byte representation, and later convert it back, as a sort of narrow waist. I could instead lay out the code paths and have different buffer types per sample type, but that ends up requiring a bunch of generated/macro code and is less preferable in my use case.
My first thought was to use bytemuck so that I don't have to carelessly shuffle pointers myself. It's just plain scalars after all. Except it's not - cpal uses the I24 type as one of the sample formats, which is defined by dasp a newtype around i32, and it doesn't implement bytemuck::Pod, so I couldn't take advantage of the crate's safety guarantees.
At this point I considered submitting this issue, but stopped to see if I could get around it by defining my own newtype (that I would implement Pod on) that maps 1:1 to your implementation and then use a little unsafe code for conversion when I need a slice to be in the other type. I thought maybe I could rely on the layout of the struct, but only then did I realize none of the non-standard sample types have a stable layout, since they don't have repr(transparent) or repr(C).
Even considering there's only one field in the struct, to my understanding this would make such unsafe casts unsound. As such I don't really have a good solution for my problem outside of the naive implementation for each sample type, or ignoring the potential unsoundness.
Would any of the changes I propose work for this crate? I'd be happy to open a PR if this seems like a reasonable direction.