I work in audio and (so far) primarily use audio libraries to output sound straight to the speakers, rather than having the library perform mixing for me. In th

I work in audio and (so far) primarily use audio libraries to output sound straight to the speakers, rather than having the library perform mixing for me. In this case, you generally write a callback to generate sound (which can be called by the audio library and outputting the results to speakers, or directly by unit tests and having the resulting audio analyzed in tests). This callback can often be entirely unaware of which audio library is being used (this may not be possible if your callback needs to react to latency and overruns), and you pass a function pointer and void* data to the audio library. The only real loss of only referencing audio-library-specific types in 1 translation unit is that the class you write to wrap audio-library-specific types must be located behind a pointer (either forward-declare class LibraryType and embed unique_ptr<AudioLibraryType>, or put AudioLibraryType or unique_ptr<AudioLibraryType> in a TU-local subclass of a public interface). Meanwhile Rust lacks the concept of translation units (instead each crate is a single rustc invocation which may sometimes be split into codegen units), and hides the presence/absence and location of compilation firewalls from the user. I don't actually know how to trigger or avoid cascading recompilations when using Rust's cpal audio library.