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

[Chris Robinson]

On Monday 05 January 2009 08:07:19 pm Ryan C. Gordon wrote:
> I did the initial legwork on defining behaviour for this, for people
> that can kick out the plug of a USB or FireWire audio device (or, say,
> redirect to different hardware outputs when plugging headphones into a
> MacBook). It has an optional special case for opening the default
> device, where you can just switch outputs and pretend nothing happened
> (like iTunes does when you plug in headphones).
>
> The extension both defines the proper behaviour and some interfaces to
> let an app gracefully handle device disconnection. We discussed this on 
> the list a lifetime ago, but I don't think it made it into any
> implementations but my CoreAudio sandbox library:
>
>      http://icculus.org/alextreg/wiki/ALC_EXT_disconnect

That's neat. :) I think there's a couple issues, though..

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.

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.

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

It's possible the device list will resize, causing a reallocation.. but the 
app would have no way to determine this and could have an invalid pointer 
access. At the very least it will change, putting the pointer at an 
indeterminate spot on the list. The compiler could also make improper 
assumptions given that the memory is marked const, when it could change.

Given that AL has no way to say "I'm done with this device list", changing it 
once the user gets it is just asking for trouble, I think.


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