This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: macOS 10.15, x86_64

Comments on the original bug report:

On 2019-11-02 03:01:14 +0000, Ryan C. Gordon wrote:

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.

On 2020-03-29 06:02:22 +0000, Ryan C. Gordon wrote:

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.