[Openal-devel] Another extension..

[Chris Robinson]

On Thursday 06 November 2008 12:18:19 am you wrote:
> One thing that concerns me a bit is that Buffer data can be used in
> several ways internally;
>
> 1. Use the data directly for the mixer (software implementation)
> 2. Copy data to the soundcard memory and use it from there.
>
> I believe 2. is the way textures are handled in OpenGL and is
> incompatible with this extension as far as I can see.

I don't see why it would be. In OpenGL, you have glTexSubImage?D (which 
similarly updates just a subsection of a texture). Likewise, a hardware 
OpenAL driver should be able to just update a portion of an on-card buffer.

Granted I don't really know how audio hardware drivers work, which is why I 
left interaction with X-RAM (the extension which lets you specify to place a 
buffer in system ram or the audio card's memory) as To Be Determined, until 
someone can clarify that it can('t) work.

> Is there a reason not to just create a new (modified) buffer and use
> that instead?

You can't change a source's buffer while it's playing, nor can you unqueue a 
buffer that's not marked processed. You'd have to pause the source, get its 
position, stop the source, detach the buffer/attach the new one, reset the 
position to the saved value, then restart it. And if you're on a hardware 
driver and low on voices, if an external system event takes a voice between 
detaching/reattaching the buffer, the reattachment will fail and you're out 
of luck. Then you'd have to do that for every source that uses the buffer 
being modified.