Added support for changing the audio playback device during runtime

[binary1248]

Added functions to:

• Get a list of available audio playback devices
• Get the default audio playback device is one is marked as such
• Get the currently used audio playback device
• Set the audio playback device to use

The API mirrors that which is already part of sf::SoundRecorder for capture devices, with a few "upgrades" for the quirks that might occur with playback devices (such as duplicate names).

Test by plugging in multiple audio devices, running the sound effects example and spamming the F1 key to your heart's content.

[coveralls]

Pull Request Test Coverage Report for Build 9269750449

Details

• 256 of 345 (74.2%) changed or added relevant lines in 7 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.009%) to 55.546%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/SFML/Audio/Sound.cpp	9	13	69.23%
src/SFML/Audio/SoundStream.cpp	15	20	75.0%
src/SFML/Audio/PlaybackDevice.cpp	7	20	35.0%
src/SFML/Audio/MiniaudioUtils.cpp	85	113	75.22%
src/SFML/Audio/AudioDevice.cpp	113	152	74.34%

Totals
Change from base Build 9256984392:	-0.009%
Covered Lines:	11520
Relevant Lines:	19612

---

💛 - Coveralls

[Bambo-Borris]

Awesome work here Binary! I'm looking forward to testing this in my own project later today, this is the kind of feature with real value to power users.

[vittorioromeo]

Thank you a lot for doing this work! I think it's a great improvement from the status quo.

My concern with this design is that we always have one global set-up audio playback device.

A user wouldn't be able to simultaneously send a few sounds to a device and few other sounds to another device, is that correct?

Use cases such as sending voice comms to headphones and game audio to speakers would not be supported if that is the case.

Have you considered a different design that would allow users to set a "default SFML playback device" but then also support the use case I described, where users can play sounds/music on specific audio devices without having to change the global set "playback device"?

[binary1248]

Updated with suggestions.

[binary1248]

Use cases such as sending voice comms to headphones and game audio to speakers would not be supported if that is the case.

Have you considered a different design that would allow users to set a "default SFML playback device" but then also support the use case I described, where users can play sounds/music on specific audio devices without having to change the global set "playback device"?

This is a very very advanced topic, one so advanced that not many AAA games even dare to support simultaneously outputting different audio streams to different audio playback devices.

While technically possible, this would require an entire redesign of the sfml-audio public API, and that is definitely out of scope for this PR and SFML 3.

[ChrisThrasher]

No structural complaints but I have a number of smaller items of feedback

[binary1248]

Updated.

[ChrisThrasher]

Is it feasible to write tests for any of these new APIs?

[binary1248]

Only if they don't have any expectations about what is returned from them... so probably not.

Addressed comments

[vittorioromeo]

Minor nitpick, LGTM otherwise

[binary1248]

Updated.

[vittorioromeo]

LGTM. This is some great work. Still need to test this with Open Hexagon but I think it's worth merging now and fixing any issues that arise later.