We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4851

Summary: CoreAudio doesn't switch devices when user chooses a new default...
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: audioAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 Keywords: target-2.0.14
Version: HG 2.0   
Hardware: x86_64   
OS: macOS 10.15   

Description Ryan C. Gordon 2019-11-02 03:01:14 UTC 
As mentioned here...

https://discourse.libsdl.org/t/changing-audio-output-when-the-default-audio-playback-device-changes/22399/5

...I'm not sure if this was _never_ supported or it broke at some point, but I think it makes sense for the NULL audio device to mean "the current system default" that seamlessly moves between devices as the user selects a new one in System Preferences (or plugs in headphones or connects a bluetooth speaker), etc.

The WASAPI backend works like this (using an SDL_AudioStream to adjust behind the scenes, if the new device suddenly needs different input parameters than the SDL audio callback was providing).

Right now our CoreAudio code picks the correct system default device when you open NULL, but it apparently doesn't migrate as the default changes (but I need to look into that to see if it used to).

Obviously if the user picked a specific, non-NULL device, we shouldn't migrate.

--ryan.
Comment 1 Ryan C. Gordon 2020-03-29 06:02:22 UTC 
Fixed in https://hg.libsdl.org/SDL/rev/682e469ffeed

Turns out we need to track the system default device ourselves, and point the AudioQueue at a new device when it changes.

I _think_ the AudioQueue manages data conversions for us here, but I don't know anything beyond loopwave worked when I toggled between my MacBook's speakers and a pair of PowerBeats bluetooth headphones. If this turns out to be a problem, we can just swap in an SDL_AudioStream as necessary, like we do with WASAPI.

For now I consider this bug resolved, though!

--ryan.