[Openal-devel] last call: ALC_EXT_disconnect

[Chris Robinson]

On Wednesday 19 August 2009 6:17:44 am Ryan C. Gordon wrote:
> > I don't think it's necessary to specify the behavior of
> > alcOpenDevice(NULL), as in question 3, as that's implementation/system
> > behavior that is not really affected by this extension. OSX already does
> > it without this extension, and having this extension doesn't guarantee
> > that behavior.
>
> This language was put in there specifically for Mac OS X. It's only in a
>   Q&A entry and not spec-enforced behaviour, though. It's just meant to
> be an assurance that if your OS already does this, it may continue to do
> so

I see. But then, I'm not sure it should be just alcOpenDevice(NULL) that can 
behave that way. I'm sure OSX has a string that opens the same device as the 
NULL device, and I believe PulseAudio can jump devices like that too, and that 
may not be the NULL device.

IMO, I think it should just be clarified that an ALCdevice isn't considered 
disconnected by OpenAL while the ALC_CONNECTED property returns ALC_TRUE. 
Whatever the implementation or system does is up to the implementation/system, 
but as long as ALC_CONNECTED is ALC_TRUE, everything will continue to function 
as normal regardless of physical (dis)connects.

> > And I don't like the idea of the enumeration strings only being valid
> > until the next query for them. IMO, the enumerations should change only
> > when the app calls something new, so existing behavior won't be changed
> > and risk breaking apps that rely on it.
>
> All four implementations in OpenAL's svn repository already do redetects
> during alcGetString() (OpenAL-Soft caches the unchanging value, but may
> do the initial detection in this call, depending on when the app called
> it), and so does mine. Keeping this string stable across queries breaks
> existing, albeit undefined, behaviour.

Hmm, okay. If possible then, something I'd like to have noted is that the 
device list may not update if there's devices open (capture or playback, 
disconnected or not). Re-probing devices could require unloading and reloading 
the backend libs, and you can't do that if there's a device open using the 
libs.