-
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
Implement Send
for Stream
#818
Comments
Same problem here, having |
As an alternative, could features be used to conditionally implement That seems to me the easiest path forward, and there is precedent in other Rust crates to do something similar. For example, the latest Bevy release conditionally implements |
So if all you would need is a Mutex, if you want to support Android. And the stream exists only as a guard to drop the callback (you don't invoke anything after creating the stream - all in the same future => no concurrency).. Then that means you can just struct SendStream(cpal::Stream)
// they see me Send-ing, they hatin'
unsafe impl Send for SendStream {} And suddenly this can all be driven from a tokio spawned future (futures::stream..). |
Currently,
Stream
does not implementSend
, and consequently, I am not allowed to move it from one thread to another in safe Rust. When I want to associate a stream with another struct that is moved between threads, I find myself coming up with the akward workaround of creating an additional thread just to create and store theStream
local to the thread:It's my understanding that CPAL and its audio backends will create dedicated threads already for audio processing, so this overhead seems wasteful and unecessary. It would be much simpler and more efficient if
Stream
wasSend
as well, and the following could simply work:To be clear, I am not asking that
Stream
beSync
, since it seems clear that aStream
shouldn't be mutated from multiple threads at the same time without additional synchronization.Browsing the CPAL source, I find this comment at src/platform/mod.rs
I'm not personally familair with Android development, nor do I have an Android device to test on, but the Android AAudio docs on thread safety say (emphasis mine):
To me, this explanation clearly rules out an AAudio backend being
Sync
, but I don't see anything here preventing the use of AAudio from separate threads at separate times. So at least superficially, it seems like an AAudio backend could indeed beSend
. It would be superb if somebody with access to an Android device would be willing to look into this and determine whether an AAudio backend for CPAL can be madeSend
and still work correctly. If I understand correctly, it would enable allStream
types to beSend
and thus make CPAL much more ergonomic to use across threads on all platforms, not just Android.Thanks for considering.
The text was updated successfully, but these errors were encountered: