[Openal-devel] ALC_ENUMERATE_ALL_EXT and pluggable sound devices

[Stefanos A.]

On Fri, 2009-09-18 at 16:41 -0700, Chris Robinson wrote:
> For languages with GC, I don't see why it wouldn't catch the references to the 
> old strings being lost when a new set is allocated and given to the app, 
> initiating a background cleanup of them.

The mere act of calling alcGetString causes an allocation & copy. There
is nothing to cache.

Yes, there are potential hacks around this issue, but do we really want
OpenAL to require hacks for efficient operation?

> 
> FWIW, I don't think it's that bad of an idea to just retrieve the list every 
> few seconds. If the cost of alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER) is 
> too high, then can't you run it in a background thread? Something like: [...]

Not really. This would solve part of the issue (high cost of device
probing) but wouldn't solve the GC problem Please excuse me for pressing
this matter but this is quite important for devices like the iPhone,
where a garbage collection *will* cause visible stuttering.

Running alcGetIntegerv from a background thread would solve the problem
completely.

On Fri, 2009-09-18 at 21:37 -0400, Ryan C. Gordon wrote:
> I think if we're going to get a fight about transferring a string 
> between C code and a managed language, there's going to be war about 
> adding callbacks.

I recall callbacks being discussed for ALC_EXT_disconnect and I don't
think anyone raised any objections other than, "OpenAL resembles OpenGL
and OpenGL doesn't use callbacks." Callbacks shouldn't be a problem, as
long as (a) they are optional (i.e. you can specify null), (b) they are
used sparingly and only within ALC, and (c) they don't pass strings
directly. :-)

OpenCL is a great example of correct callback use. You can register
simple callbacks if you need extra information on context-, device- and
compiler-related matters, but you are not required to do so.

GLU is an example of what to avoid: its tessellation API is essentially
unusable from managed languages, as it relies on callbacks to pass
arrays of data. Works ok in C/C++ (where arrays are pointers), but
causes problems for everything else.

Here are my notes about this format...
> 
>      alcGetBoolean(ALC_DEVICE_LIST_CHANGED, &trueOrFalse);
> 
> - There's no alcGetBoolean. We could use alcGetIntegerv(), though.
> - It's a little annoying to have something that only works with the
> NULL 
> device in alcGetIntegerv() ...but it's not a big deal, I guess.

Not really an issue.

> - Is "changed" useful? We don't know if something was added or
> removed 
> without checking the list against a previous copy. If we're going to
> do 
> this, we should probably make it more useful than just telling you
> that 
> you need to reparse the device list.

Sounds useful and shouldn't be any harder to implement than a simple
true/false value. Something like the following maybe?

alcGetIntegerv:

    'data' - returns ALC_DEVICE_REMOVED, ALC_DEVICE_ADDED,
ALC_DEVICE_UNCHANGED when 'param' is ALC_DEVICE_LIST_CHANGED.

> - Do we report this to be true for each device that changes, or once
> for 
> each pile of changes between queries?

Once only (the user is expected to re-parse the device list at this
point).

> - Is this value true or false at startup?
> - What happens if the app doesn't check this? Does it report true
> until 
> queried, and then resets to false? What happens if they request the 
> device list without checking this flag?

These are important questions. Possible solution: this query returns
true (or ALC_DEVICE_ADDED / ALC_DEVICE_REMOVED) until the user calls
alcGetString to retrieve the device list. At that point, it resets to
false / ALC_DEVICE_UNCHANGED until the device list is modified.

With this approach, the initial value should be true / ALC_DEVICE_ADDED,
which will be reset to false / ALC_DEVICE_UNCHANGED as soon as he
retrieves the device list.

> - I don't think this changes anything about when the AL does device 
> redetects. It may still have an event queue internally, or be
> checking 
> on another thread internally, or do it during the app's query.

> This will need a new extension...all the things we're talking about
can 
> coexist with ALC_EXT_disconnect, and won't need to rely on it, either.

I think it's cleaner (and simpler to implement) this as a separate
extension. Maybe "ALC_EXT_device_notification"?

The important part is that the user be notified of device changes
without worrying about the implementation details (i.e.
alcGetIntegerv(ALC_DEVICE_LIST_CHANGED, ...) might  return a cached
value or it could cause a device probe - the user shouldn't have to
worry about this.)

Note: I don't think callbacks are necessary or useful for this
extension. In fact, they may be rather difficult to implement on
platforms that need probing (instead of device events).