[Openal-devel] ALC_ENUMERATE_ALL_EXT and pluggable sound devices

[Ryan C. Gordon]

Daniel PEACOCK wrote:
> 
> 
> 
> Hi,
> 
>> Day by day, pluggable devices become even more popular. They are cheap
>> and very attractive for mobile users. Some of pluggable USB sound
>> devices have good quality. For this reason, it is not suitable anymore
>> to be obliged to restart an application (or a game) after connecting a
>> device to be able to use it... And I think that  ALC_ENUMERATE_ALL_EXT
>> extension should reflect devices changes of the system.
>>
>> A second problem was that I could't list the current connected USB
>> device by using ALC_ALL_DEVICES_SPECIFIER. Inspecting some OpenAL code
>> in SVN (specifically the Windows Router code), I discovered that the
>> variables g_pDeviceList, g_pCaptureDeviceList and g_pAllDevicesList are
>> initialized only once, in the occurrence of calling opening functions
>> like alcOpenDevice (see the function BuildDeviceList).
> 
> I agree that this is a problem that needs to be solved.  The reason why
> these variables are initialized once is purely as an optimization to
> prevent repeated loading and unloading of DLLs.  However, I think you are
> probably right - it would be better to always get an up-to-date list of
> available devices when calling the enumerate calls (ALC_DEVICE_SPECIFIER
> and ALC_ALL_DEVICES_SPECIFIER).
> 
> The tricky part is, perhaps, how an application knows that it should
> refresh the available devices.  e.g. An application should definitely not
> keep calling an enumerate function just to see if anything is different -
> that would be really slow.
> 
> Ideally if the Router detected a change of audio devices, then it could set
> a flag that enables a refresh of the device lists on the *next* call to an
> enumerate function.  (We could even add a new function that the application
> can call to determine if the device list has potentially changed).

Shouldn't the router just delegate this responsibility to the actual AL 
implementation? Once it picks a lowlevel implementation it probably 
shouldn't ever pick a new one. But if a given implementation handles 
ALC_EXT_disconnect, then it should do all the work.

So a hardware-specific AL does its thing, and if it only handles a chip 
welded to the motherboard, it doesn't expose ALC_EXT_disconnect. If 
it's, say, a generic DirectSound implementation, it handles the 
extension, and deals with USB devices coming and going.

No changes to the router needed, no constant rechecking of various DLLs. 
It seems reasonable to me.

--ryan.