feat(coreaudio): make Stream implement Send on CoreAudio #1021
Conversation
roderickvd
changed the title
roderickvd
changed the title
There was a problem hiding this comment.
I suspect we can not do this without spawning a separate thread to keep AudioObjectPropertyListener in. Maybe its perfectly safe maybe its not. There is not enough documentation from Apple to judge that.
Lets give Apple users an extra thread doing nothing but keep that object on the same thread.... We should name the thread: apple_should_document_their_audio_api \s
|
@dvdsk good catch. Let's be more conservative. I've reworked this to use a dedicated thread. While I was at it, I also killed the |
roderickvd
changed the title
|
This should be in a good state now - thanks @dvdsk for the necessary reviews. I'll rebase and if you agree, we can merge. |
roderickvd
force-pushed
the
feat/coreaudio-send-stream
branch
from
77ba291 to
3e765e1
Compare
…ustness - Use try_lock to avoid panics and recover from poisoned locks when invoking error callbacks - Skip error callback if lock is busy - Enhance disconnect listener thread to report creation errors and ensure proper synchronization - Update stream lock error message for clarity
Consolidate repeated error callback logic into invoke_error_callback for better readability and maintainability. Update usages in device.rs and disconnect manager. Add documentation for the helper.
roderickvd
force-pushed
the
feat/coreaudio-send-stream
branch
from
3e765e1 to
25b2135
Compare
|
It would be nice if various backends could be tested on their send-ness, to make sure this doesn't accidentally regress. Something on the lines of const fn assert_send<T: Send>() {}
const _: () = assert_send::<Stream>();maybe, so that a non-send stream is a compile fail? |
Streamcan now be moved between threads safely on macOS.Rc<RefCell<>>withArc<Mutex<>>for thread-safe access to stream stateDisconnectManagerto isolate non-SendAudioObjectPropertyListenerunsafe impl Sendimplementations that are now automatically derivedThe mutex is only locked during
play()andpause()operations, so performance impact is negligible. The audio callback is completely unaffected.