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

[Chris Robinson]

On Wednesday 07 January 2009 02:24:56 Ryan C. Gordon wrote:
> > 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.  :)

True, I suppose..

> 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.

Or the meta-device could be the default device, so opening NULL would 
implicitly select it when available. To me, it seems like something the user 
would tell from looking at the device name list, or the implementation would 
handle smartly, than to try to pragmatically tell which devices are meta-
devices.

> > 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.

I think it's a bit misleading, in the end. It gives the impression that if you 
want a device that can reconnect to other physical devices, you need to use 
NULL, since no other devices can switch. It seems to be an implementation 
detail for a given device name than something that may be possible behavior 
for a special NULL device.

As an example, Creative's drivers have a "Generic Software" device, where 
there's no reason it can't auto-switch; but users would be encouraged to 
select NULL for that behavior instead, where it would pick "Generic Hardware" 
if available, preventing auto-switching.

And if you can't guarantee that NULL will select a device capable of auto-
switching, when there are some that may be able to, it becomes impossible to 
rely on and has no point, IMO.

> 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.

Sounds good.

> > 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.

Right, but then it's the app's choice if it wants to continue trying to 
restore the device, or do an entire sound system reset. It could even allow 
apps to pop up a warning to the player after a given number of restore 
attempts:

The current sound output device seems to have been disconnected
            Restore Device  /  Restart Sound System

..giving the player a chance to plug the device back in and restore it, 
instead of automatically switching to something else or shutting down 
outright.


Really, my main concern here is having something like ALSA detect a failure 
from the device and have that taken as a disconnection (since I don't think 
there's a specific "device lost" failure), forcing the app to shutdown the 
audio system and restart it, if instead it can try to restore the device 
without messing around like that. I wouldn't want to jump at the first sign of 
problems from ALSA, but how long do you retry to bring it back before it's a 
lost cause? Since a device marked disconnected will never reconnect, I can't 
"take it back" if the device comes back.

> 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.

I'm not really sure what OpenGL's spec says about keeping local copies of 
textures, but I do know it's the implementation's responsibility to restore 
textures that get clobbered, and there can be very many textures loaded at a 
given time. I can't say I know how often clobber events happen though, so 
maybe they just ignore it and hope for the best?