[openal] Runtime devices management

[Chris Robinson]

On 09/12/2016 03:44 AM, alberto box wrote:
> The extension "ALC_EXT_disconnect" results available, but it doesn't work
> in my environment: ... it keeps on telling me the capture device is present
> even when I unplug it, and even after the dll replacement. Well, anyway I
> think I can replace it with a periodic scan of devices list.

Odd. Are you regularly checking the samples available? OpenAL Soft won't 
actively receive a device-lost event from the system (for mmdevapi and 
dsound, at least), and instead only knows if it's been lost when it 
tries to use it. For performance reasons, since it's supposed to be 
checked relatively often, querying AL_CONNECTED will only report the 
last known status instead of asking the system if the device is still there.

If you are querying and reading samples from the device, and it's saying 
the device is still connected, then Windows is likely hiding the fact 
that it's lost. It might do that in the hopes that the device will be 
reconnected and it can resume, or it may be a deficiency in Windows' 
DSound layer.

> Are you aware of any sideffect/issues that can be raised by the dll
> substitution and that can affect the application behavior?

The biggest side effect is that you'll only get OpenAL Soft devices, 
even if other OpenAL drivers are present.

Aside from that, alGetError() will return an error if it's called 
without a current context. With Creative's router, it will always return 
AL_NO_ERROR without a context (and other al* functions would no-op, so 
you could call alGenSources and alGetError without a context and think 
the call was successful, even though it wasn't). OpenAL Soft will 
instead return AL_INVALID_OPERATION, so you'll know it didn't work.