For the cause of audio, I don't see why they would make a particularly good example. You'd probably want to switch audio output methods (to support *no* audio, at least). And anywhere likely to want audio access is probably going to need access to the display and other critical components - you might as well bundle all that together in a UserOutput object, and pass a reference to that around.
I'm writing just the audio library, not a game
It depends on what you need. The whole 'static initialization problem' only occurs when static objects depend on something in another unit for their initialization. Something like this:
Is 100% safe. The danger comes with things like this:
std::vector<int> my_ids = function_in_some_other_file();
If function_in_some_other_file() is dependent on other static objects, the order of initialization is now a problem. However, this sort of thing happens so infrequently that it honestly amazes me how often people cite it. I don't think I've ever come across it.
I had problems with the 'static initialisation order fiasco' before, that's where my concerns come from. What I'm worried about is what if the programmer decides to initialise an object of my class (the sound source class) statically, and the object (in it's constructor) references parts of my library that are also initialised statically.
I'm actually pretty curious about these sound sources as well.
What are they to be used for? (Music, sfx)
Are they very performance intensive, or are they super lightweight?
What needs access to them, and when?
Do you have a limit on the number that can exist?
Are there special considerations, like in order to create one you have to load the audio file, which takes a lot of time, so you need some kind of caching solution?
The sound source class is for creating objects that are supposed to play sounds that can move around and change. For example if I'm making a racing game then each car could have a source object (or even more than one) to play its sounds. The source objects have properties like the name of the sound file they are playing, position, pitch, loudness, velocity etc.
They are pretty lightweight because they are just a level of abstraction on top of the mixer.
There is no limit to the number of them (this is actually the main reason I am writing this library).
Who needs access to them really depends on the application, but I would imagine that if you are writing a game you want to make those sources a part of your classes, so that things like player, bullet, car etc have their own sound sources packed inside.
There are no special considerations, the sources are completely abstracted from the actual underlying sound module, they only store and manipulate information needed by the mixer to play sounds BUT I need to register every source object upon creation and unregister it upon destruction so the mixer always keeps an up-to-date list of all sources.