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

[Chris Robinson]

On Monday 05 January 2009 01:21:21 pm Bob Aron wrote:
> OpenAL Community,
>
> Can anyone that is familiar with the other (non- Mac) implementations
> describe these behaviors when there are device changes?
>
> 1) What does the implementation do when the device being used goes
> away? (and later returns?)

As far as OpenAL Soft is concerned, it depends on the backends. For ALSA, 
DirectSound, and SDL, I'd imagine it would just stop processing any contexts 
for those devices until they come back (I'd hope they'd go into a perpetual 
state of device-not-ready or buffer-lost, where it would regularly try to 
bring them back). For OSS or Solaris, I'm not sure what their specifications 
say about that condition (whether they'll block or just return 0 bytes 
written, or return -1).

It's also possible the device becomes completely invalid and processing on the 
context stops indefinitely (until destroyed). Though I'd think at least ALSA 
would deal with lost devices sanely. Can't say I've tried though, as I don't 
have any "removable" audio devices.

OpenAL itself doesn't have a mechanism for dealing with this condition, though 
I think it's been requested. It's undefined behavior. I've been thinking of 
making up extensions for generic query objects (like OpenGL has) that could 
handle these things.. context/device state, DSP time, fencing(basically 
saying when an AL command has been processed), maybe even current 
output/per-source amplitude..

> 2) What does the implementation do when the format of the device
> changes (i.e. channel count, sample rate, bit depth)?

I don't believe that's possible for OpenAL Soft's backends. Once it get a 
voice, it doesn't let anything else have it. In the cases where it may be 
possible (eg. ALSA's dmix, DSound software mixing), it's silently converted 
to the new output format by the backend.

As far as the spec is concerned, an implementation could do anything it 
needs.. try to set the format back, start mixing with the new format, or even 
fail to process anything more if there's no other choice.

> 3) How does the user and/or implementation map the channels being used
> to the speakers connected to the system?

OpenAL doesn't give you access to the channels, and there's no way for an app 
to know how many there are or what they're for. The AL_FORMAT_ formats have a 
specific channel ordering regardless of the output (AFAIK).

I've tried to think of ways to at least report the output format, but the 
methods were error prone (returning formats the app may not recognise) and/or 
ambiguous (returning generic information, not saying anything about the 
actual configuration).

> I don't believe there is any contract in the specification that states
> the implementation must present every device on the system, since it
> possible some devices may be incompatible for use.

It doesn't, but it's kind of expected to. Since as far as I understand it, a 
user can set the "default device" to any specific device, so OpenAL will 
still have to deal with these conditions in some way.