[Openal] Defective ALC_ENUMERATION_EXT support on Mac OS X / Need
OpenAL community's support
chris.kcat at gmail.com
Mon Jan 5 14:42:21 PST 2009
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
> 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
> 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.
More information about the Openal