|
»
« Return to Thread: Bug in ALUT_WAVEFORM_SINE?
Re: Three Extensions
by Chris Robinson-5
::
Rate this Message:
On Monday 23 February 2009 7:55:08 am Richard Furse wrote:
> > 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.
It would actually make it more difficult, because if the capturing/rendering
is done asynchronously, the callback would be called asynchronously. As such,
the user would be responsible for keeping thread safety. It would also make
things difficult because of the internal locks going on that the user app has
no idea about, and the sensitive timing needed to get the rendered data out to
the sound device. The safest thing for an app to do would be to just set a
flag to check later..
> 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.
At the very least, a user data handle will be needed so the bindings can store
the needed info for calling between the wrapper callback and the real user
function. But I think it's better left alone than to try it this way.
> > 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.
A bit more work, but you get a bunch of flexibility in return.
> > 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.
That's another benefit of keeping it in AL buffers. It can all be done
asynchronously without having to push data around. It can write to the same
memory segment that's read from, which doesn't even need to be in system RAM.
All you do is get the event that the buffer is complete, then you remove it
from one queue and put it in another.
> Let me know if you're planning to code up something like this - perhaps we
> could coordinate to make sure we've consistent implementations.
There could be an issue with how to actually do the render. In OpenAL Soft, a
user can set 5.1 or 7.1 output.. but since the foldback can only take mono or
stereo, it requires additional re-channeling. Not a huge deal, but something
that may need consideration.
Also, there's a question of how to split it up. I don't think a render-to-
buffer extension would be the best place to introduce an alGetBufferData
function (since it's perfectly usable without requiring an implementation to
handle render-to-buffer). But if it's going to be its own extension, there's
other buffer-related things that can be added, too.. for example, the number
of sample frames/length in time is something I would find useful). The query
stuff could also be done generically, so it can be reused with other
extensions.
> However, we've gone the effect route as it allows the game to choose to
> boost the LFE of something that's already playing.
If you use an effect to feed data into the center or lfe channel, you could
also lose the ability to have another effect going at the same time. OpenAL
Soft and Creative's software driver both allow you to create only one effect
slot, so if you have a mono-to-center effect set on the slot for a narrative,
you can't apply reverb to any other sources that may be playing. You couldn't
even apply a mono-to-lfe effect on another source.
A buffer or source attribute wouldn't have that problem. It wouldn't even
require EFX. If it's a source attribute, the same buffer can be used on two
sources.. one that maps it to LFE, and one that plays it normally.
> > 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.
Yeah. The main thing is AL_ORIENTATION being valid only if a B-Format buffer
is being used. Since a source already uses half of the orientation data, I
don't see why it couldn't just use it regardless of the format. If your app is
"B-Format aware", then you can just use AL_ORIENTATION and forget about
AL_DIRECTION; and "B-Format unaware" apps can use AL_DIRECTION without a
problem since only B-Format buffers will use the up-vector.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
> > 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.
It would actually make it more difficult, because if the capturing/rendering
is done asynchronously, the callback would be called asynchronously. As such,
the user would be responsible for keeping thread safety. It would also make
things difficult because of the internal locks going on that the user app has
no idea about, and the sensitive timing needed to get the rendered data out to
the sound device. The safest thing for an app to do would be to just set a
flag to check later..
> 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.
At the very least, a user data handle will be needed so the bindings can store
the needed info for calling between the wrapper callback and the real user
function. But I think it's better left alone than to try it this way.
> > 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.
A bit more work, but you get a bunch of flexibility in return.
> > 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.
That's another benefit of keeping it in AL buffers. It can all be done
asynchronously without having to push data around. It can write to the same
memory segment that's read from, which doesn't even need to be in system RAM.
All you do is get the event that the buffer is complete, then you remove it
from one queue and put it in another.
> Let me know if you're planning to code up something like this - perhaps we
> could coordinate to make sure we've consistent implementations.
There could be an issue with how to actually do the render. In OpenAL Soft, a
user can set 5.1 or 7.1 output.. but since the foldback can only take mono or
stereo, it requires additional re-channeling. Not a huge deal, but something
that may need consideration.
Also, there's a question of how to split it up. I don't think a render-to-
buffer extension would be the best place to introduce an alGetBufferData
function (since it's perfectly usable without requiring an implementation to
handle render-to-buffer). But if it's going to be its own extension, there's
other buffer-related things that can be added, too.. for example, the number
of sample frames/length in time is something I would find useful). The query
stuff could also be done generically, so it can be reused with other
extensions.
> However, we've gone the effect route as it allows the game to choose to
> boost the LFE of something that's already playing.
If you use an effect to feed data into the center or lfe channel, you could
also lose the ability to have another effect going at the same time. OpenAL
Soft and Creative's software driver both allow you to create only one effect
slot, so if you have a mono-to-center effect set on the slot for a narrative,
you can't apply reverb to any other sources that may be playing. You couldn't
even apply a mono-to-lfe effect on another source.
A buffer or source attribute wouldn't have that problem. It wouldn't even
require EFX. If it's a source attribute, the same buffer can be used on two
sources.. one that maps it to LFE, and one that plays it normally.
> > 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.
Yeah. The main thing is AL_ORIENTATION being valid only if a B-Format buffer
is being used. Since a source already uses half of the orientation data, I
don't see why it couldn't just use it regardless of the format. If your app is
"B-Format aware", then you can just use AL_ORIENTATION and forget about
AL_DIRECTION; and "B-Format unaware" apps can use AL_DIRECTION without a
problem since only B-Format buffers will use the up-vector.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
« Return to Thread: Bug in ALUT_WAVEFORM_SINE?
| Free embeddable forum powered by Nabble | Forum Help |
