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 - CoreAudio doesn't switch devices when user chooses a new default...
Summary: CoreAudio doesn't switch devices when user chooses a new default...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: HG 2.0
Hardware: x86_64 macOS 10.15
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.14
Depends on:
Blocks:
 
Reported: 2019-11-02 03:01 UTC by Ryan C. Gordon
Modified: 2020-03-29 06:02 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.