[Openal] Defective ALC_ENUMERATION_EXT support on Mac OS X / Need OpenAL community's support

[Ryan C. Gordon]

> Using GL as an example, you don't typically use GLX/WGL calls once the context 
> is setup.

...but you would if you wanted to know if the X server dropped your 
connection.  :)

> I'd think an implementation could do that by exposing a meta-device, of sorts. 
> Like how OpenAL Soft gives a "ALSA Software on default" device, if the current 
> default device is disconnected, it could reopen the new default device, and 
> continue on with that, leaving the app none-the-wiser. Open a specific one, 
> like "ALSA Software on HDA NVidia [ALC883 Analog]", and it wouldn't.

It could certainly do that, but then applications would be in the 
business of parsing implementation-specific strings to find it, or 
forcing the user to select it from a list. NULL is the cleaner way to 
request this behaviour, for platforms that support it.

> IMO, letting work through meta-devices would be better overall than only 
> specifying that NULL can do it. It allows implementations to be smarter about 
> device groups, even possibly giving more options for the user (eg. don't 
> switch to speakers if these headphones are lost).

I don't think the extension prevents this sort of behaviour. For power 
users, such a meta-device could be very useful, but it's out of scope 
for ALC_EXT_disconnect.

> Sounds a bit safer, but maybe still a bit problematic in multi-threaded 
> situations (then again, AL itself isn't the greatest when dealing with 
> threads..).

I amended the spec to say the string survives until the next query, 
which implies "you should use a mutex, if you really need to get the 
device list in two threads at once for some reason".

I also warn that device enumeration may no longer be a "fast call," 
since device (re)detection may now be happening on each query.

> I wouldn't say that. All the existing objects would remain, and the state 
> would remain. You wouldn't need to worry about a device getting selected that 
> may have lesser capabilities than what you set up with, or risk failure during 
> reinitialization leaving you in a bad state. Anything holding handles to AL 
> objects won't have issues.

This is a good point, but if you want a fallback path for devices that 
are _not_ going to return, you'd still need to select a new device, and 
that's going to need all the state reset in any case. Restore() in 
DirectX is usually meant to be done in a loop until it succeeds (you got 
the device back from a higher-priority process that temporarily stole it 
by alt-tabbing back to your game, etc), but I'm wondering what happens 
when the device is never coming back. I would still guess that both 
DirectSound and most games behave badly.

> Given that OpenAL is working off OpenGL's example, AL could take care of 
> restoring clobbered buffers for you automagically when restored, just like GL 
> restores lost textures. If you close/reopen the device, you pretty much need 
> to restart the app's sound system in the middle of play, whereas restoring it 
> could leave you as you were.

I'm not sure that it's fair to make an implementation keep a malloc()'d 
copy of all your buffers around if the hardware can hold it all, just in 
case there's a catastrophic failure. The app can optimize for this case 
better, such as reloading from disk, etc.

> True enough. My initial idea was to use a query API, like GL has:

It's a little heavy for what we're doing here. The value of the GL query 
API is that you can ask questions that take time to figure out and pick 
up the answer later without blocking. We honestly might become 
interested in hardcore audio occlusion at some point, but it adds more 
work for the app and the generation of what, in this case, is a needless 
object and associated state for the AL.

--ryan.