Re: Three Extensions

On Monday 23 February 2009 4:40:17 am Richard Furse wrote:
> Hi there - I'm getting close to releasing a new software Ambisonic OpenAL
> implementation (it was demoed at the recent AES games conference) I've
> added some extensions and I thought I should present them for comment here
> before registering them with the database.

Hi. Good to see another OpenAL implementation springing up. :)

> The extensions are:
> * AL_EXT_FOLDBACK (see al-foldback.h, enclosed) is an extension to
> allow a mixdown of the game's audio to be fed back to the game in mono or
> stereo.

Render-to-buffer (or generally some way to render so that an app can read back
into a buffer), has been requested for some time. Unfortunately, given the
asynchronous, real-time nature of OpenAL, it's a bit difficult to come up with
a method that's efficient enough, simple to handle, and flexible.

The main thing that strikes me about this proposal is the use of a callback.
I'm not sure this is very flexible or simple  with language bindings.
Considering neither OpenAL nor OpenGL have callbacks anywhere in its core API,
I would assume this is because of portability concerns.

Maybe some kind of query mechanism would work better? eg. Set up an query to
watch for 'foldback events', which can be retrieved when one is available. The
events would be polled by the app instead of a callback being called.


Perhaps also, instead of writing to user memory, it can write to a buffer
queue. The user queues up a certain amount of buffers then calls
alRequestFoldbackStart. When an AL_FOLDBACK_EVENT_BLOCK event occurs, the
buffer can be unqueued, and another buffer can be queued to keep it going
(similar to how source buffer queues work, except its for writing instead of
reading). If the queue ever becomes exhausted, it automatically stops and
sends the appropriate event.

Should the data be needed in user memory, AL buffers can be given an
alGetBufferData function to retrieve it. eg:
if(event == AL_FOLDBACK_EVENT_BLOCK)
{
    alFoldbackUqueueBuffers(1, &bID);
    alGetBufferData(bID, format, freq, datalen, data);
    alFoldbackQueueBuffers(1, &bID);
}


I'm imagining that in addition to simply recording what you hear, an app can
create a "playback-less context" with a special context creation flag. An app
would use that context exclusively for foldback operations, and the buffers
would be shared with the playing context on the same device. This would allow
you to render a completely different environment than what's being heard by
the player.

> * Two new effects (AL_EFFECT_DEDICATED_LOW_FREQUENCY_EFFECT and
> AL_EFFECT_DEDICATED_DIALOGUE, see efx-dedicated.h) to route audio directly
> to LFE or centre speakers where present.

I think these would work better as explicit buffer formats:
AL_FORMAT_LFE[8|16|32]
AL_FORMAT_CENTER[8|16|32]

Or maybe some kind of buffer flag..
alBufferi(bID, AL_MONO_TO_CENTER, AL_TRUE);
// or
alBufferi(bID, AL_MONO_TO_LFE, AL_TRUE);
The buffer would be treated as multichannel (in that it doesn't get
spatialized and may not get sent through the source sends), and would have no
effect if the buffer data is multichannel.

> * AL_EXT_BFORMAT (see al-bformat.h) allows multichannel buffers to of
> first order Ambisonic B-Format data. This extension also implies the
> ability to re-orient these buffers via alSourcefv() and alListenerfv().

Can't say much about this since I'm not very familiar with Ambisonic. I assume
you need both an 'at' and 'up' vector for sources, not just 'at'? Perhaps this
can be generalized so that all sources can accept AL_ORIENTATION, but allowing
for the 'up' vector to be ignored. Setting a source's AL_ORIENTATION would
overwrite its AL_DIRECTION with the given at-vector, and setting a source's
AL_DIRECTION would overwrite the at-vector and leave the up-vector undefined.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel