« Return to Thread: Bug in ALUT_WAVEFORM_SINE?

RE: Three Extensions

by Richard Furse-2 :: Rate this Message:

> -----Original Message-----
> From: openal-devel-bounces@...
> [mailto:openal-devel-bounces@...] On
> Behalf Of Chris Robinson
> Sent: 23 February 2009 14:50
> To: openal-devel@...
> Subject: Re: [Openal-devel] 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. :)

Thanks :-)

It's called "Rapture3D".

> > 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.

I guess I've gone for simple and efficient, but not 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.

Yep - I considered this, but came to the conclusion it was best to notify
the app, in the style of most other inbound APIs. This keeps thread sync
really simple. If the app really can't cope with the language binding (is
there really much stuff not in C/C++?) we could always shove a standard
callback implementation in ALUT to store the callbacks and list them back on
request.

> 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);
> }

Yep, I can see that would work and is more elegant in many ways, though
there are quite a few moving parts and it would probably be quite a bit of
work to do right.

> 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.

Ooo. That's rather interesting, though it might need some work to make sure
we didn't end up inducing a lot of overall latency.

Let me know if you're planning to code up something like this - perhaps we
could coordinate to make sure we've consistent implementations.

> > * 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.

Yup, that would work.

However, we've gone the effect route as it allows the game to choose to
boost the LFE of something that's already playing.

> > * 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'?

Yep, this is exactly what we've done, hence the use of AL_ORIENTATION.

> 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.

Interesting... I guess most games wouldn't NEED this as they'll know which
of their sources are in B-Format, but it would be very easy to add.

Thanks!

--Richard

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

« Return to Thread: Bug in ALUT_WAVEFORM_SINE?