[Openal-devel] ALC_ENUMERATE_ALL_EXT and pluggable sound devices

[Guilherme Balena Versiani]

Stefanos A. wrote:
> Besides, why allocate a new string every 5 seconds when you could just
> say:
>
> if (alcGetBoolean(NULL, ALC_DEVICE_LIST_CHANGED))
> {
>     // retrieve device list
> }
>
> ?
>   

I don't agree with this approach. But let me explain first why I am 
saying this below.

Let me divide the pluggable devices problem:

  1) There should have some mechanism to reset the device listing to get 
any new device connected or disconnected from the system.
  2) There are applications that needs to know if some new device was 
connected.

I think the first problem should be solved by just calling 
alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER) once again. The 
application should not expect to maintain the same listing if you call 
alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER) a second time... If the 
application does not like to get devices changes, then it just calls 
alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER) once, in the 
initialization of the program. This call (enumeration) does not need to 
be reentrant, so the solution is very simple... I don't like to rely on 
an extension, that can be implemented or not by the current installed 
OpenAL driver, to use something that IS NEEDED by my application or game.

The second problem could be solved by inspecting the USB bus (or 
FireWire, etc) using some kind of O.S. API. But IMHO, OpenAL itself 
should not be responsible for this, as this activity is very complex, if 
you want to implement an efficient approach (the devices API is very 
different between operating systems). But if someone wants to develop 
this mechanism, I think you can do something like:

    void my_callback(...) {
        ...
        alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER);
        ...
    }

    alpnpMonitorDevices(&my_callback);

Why I does not like the proposed solutions:

    1) Stefanos solution ( alcGetBoolean(ALC_DEVICE_LIST_CHANGED) ): you 
need to make polling on your program, even if you have a more robust 
implementation in lower-level. For example, tomorrow you find that is 
more simpler and have less cost to receive some kind of system 
notification (that is available on most of current operating systems) in 
the event of a device connection.
    2) Ryan solution ( new memory allocated on the return of 
alcGetString function ): you will broke the behavior of the function, so 
old code implementations will start to leak memory after this change.

I would like to receive comments about the above proposal and why you 
couldn't adopt it (I don't know deeply which kind of requirements are 
involved in alcGetString API).

Regards,

-- Guilherme Balena Versiani.