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

[Ryan C. Gordon]

> To me, it seems out of place for the app to have to check the device itself. 
> Everything else you do when working in the context is done through the 
> context, and needing to keep around and regularly use a device handle because 
> of the potential event that a device can be lost seems a bit unnecessary 
> (especially when you consider you don't necessarilly have a device handle 
> when you use things like alut or alure). You can always get them after you 
> determine the problem, but I don't think you should need them otherwise.

The proper granularity is the device, I think...multiple contexts on the 
same device would all go when the USB stick is pulled out.

As for ALUT, this doesn't seem like a deal breaker to me:

bool stillConnected()
{
     ALCint yesOrNo = 0;
     alcGetIntegerv(alcGetContextsDevice(alcGetCurrentContext(),
                    ALC_CONNECTED, sizeof (yesOrNo), &yesOrNo);
     return (yesOrNo != 0);
}

> I'm also not sure I like the fact of the default (NULL) device behaving 
> differently once selected. Personally I'm not sure it should even behave 
> differently from selecting *the* default device given the language of the 
> spec, but I can see the use in automatically selecting any useable device.

This was partially a concession to CoreAudio, because it fits the 
expected system behaviour on Mac OS X. If you change your default audio 
device in System Preferences while iTunes is playing, it starts playing 
your MP3 on the new device without skipping a beat. Likewise for 
plugging in headphones, etc. It's pretty sweet.

I think the CoreAudio model is just too compelling here, and I expect 
that most other platforms won't take advantage of this. We only do this 
with the default device, since that is sort of like telling the AL that 
you don't really care, please make a best decision for me. It just 
continues to do so thereafter. If you request a specific device, it 
shouldn't ever switch out from under you.

> Plus the enumeration list changing on a whim could cause a problem. Take, for 
> example, the scenario:
> 
> const char *devlist = alcGetString(NULL, ALC_DEVICE_SPECIFIER);
> while(*devlist) {
>     printf("%s\n", dev_list);
>     devlist += strlen(devlist)+1;
>     <device (dis)connected>
> }

We can say that the string is valid until the next call to 
alcGetString(device, ALC_DEVICE_SPECIFIER). The implementation has to 
either cache the current string, or only do device redetects when 
ALC_DEVICE_SPECIFIER is requested. I'll clarify this in the spec.

> Also, isn't it be possible for a disconnected device to come back and be 
> restored? With DirectSound, its buffers (ie. AL sources) can return 
> DSERR_BUFFERLOST, then you can call the Restore() method to try to bring it 
> back.

I think these errors are meant for other apps stealing the device (like 
how Alt-Tab will cause a Direct3D fullscreen device loss), more than the 
device vanishing. If DirectSound handles physical device removal at all, 
I assume that Restore() just fails permanently (the API allows for that).

Even in the case that Restore() succeeds, your data is still gone and 
has to be reuploaded. At which point, you're really not doing much 
differently in this extension, where you close and reopen the device. 
The only thing Restore() adds is that it would, in theory, handle 
finding the device for you, if that actually works at all.

> For OpenAL, what about making operations on sources (and EFX effect 
> slots?) potentially generate AL_DEVICE_LOST errors, then have an 
> alcRestoreDevice method to try and bring it back? The alc* functions could 
> generate ALC_DEVICE_LOST errors, too.

For what it's worth, I hate that every entry point in DirectX can fail 
with device loss. It is, strictly speaking, an error condition, but it's 
more like an exception, so checking it once a frame seems more 
reasonable to me.

Also, OpenGL's evolution proved interesting: calling glGetError() can 
stall the GL. All pending operations have to finish before it returns, 
and (theoretically) correct programs should never generate an error, so 
modern programs _never_ call it, except in debug builds...things that 
would force OpenAL apps to call alGetError() all the time, or even once 
a frame, should be special-cased like this extension does.

--ryan.