Map/Unmap API

[Chris Robinson-5]

Since the subject of OpenAL 1.2 has come up a couple times, perhaps this
should be discussed (again?).

In OpenGL, you can create PBOs to store pixel data to read from and write to
textures and render surfaces. It allows for fast access as calls like
glTexImage2D and co. can be scheduled to occur later and via DMA transfers. It
also allows an app to map/unmap it to read and/or write quickly.

Something like this could be useful to OpenAL too, I think. Often times when
audio is decompressed, it requires the app to have a memory segment to write
to and give to alBufferData. Since alBufferData needs to finish with the user
pointer before returning, this would cause unnecessary waiting while it's
copied and potentially converted. This would also be an issue for real-time
generated streamed sounds.


I don't think it would be too difficult to implement a basic proof-of-concept.
I would only ask how it would be named, since OpenGL's use of 'Buffer' is
already taken. It could be given a name like 'Databuffer' (kind of wordy) with
a new set of functions, or override OpenAL's buffers to behave that way when
alBufferData is called with AL_NONE for a format with a couple new functions
to handle it. With the latter, the frequency would be ignored, buffers that
use AL_NONE can't be queued or attached to a source, and buffers that don't
use AL_NONE can't be 'bound'. Reading the AL_SIZE property would work as
expected, and AL_CHANNELS/AL_BITS/AL_FREQUENCY would give 0.


Thoughts, comments? If there's no serious objections, I'll try playing around
with the idea.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Sherief N. Farouk]

> In OpenGL, you can create PBOs to store pixel data to read from and
> write to
> textures and render surfaces. It allows for fast access as calls like
> glTexImage2D and co. can be scheduled to occur later and via DMA
> transfers. It
> also allows an app to map/unmap it to read and/or write quickly.
>
> Something like this could be useful to OpenAL too, I think. Often times
> when
> audio is decompressed, it requires the app to have a memory segment to
> write
> to and give to alBufferData. Since alBufferData needs to finish with
> the user
> pointer before returning, this would cause unnecessary waiting while
> it's
> copied and potentially converted. This would also be an issue for real-
> time
> generated streamed sounds.
>

I suggested this on the mailing list in March 2008, But it didn't make it
through (You can check the thread, called "Faster buffer model, and more
random stuff" for details of the discussion). Since then, I've implemented
two revisions of this map/unmap buffer model (the latter more strongly
worded than the former) and found it to be a bit faster (especially on
in-order architectures) and it saved me having to use a proprietary
extension on a gaming console, so I'd highly recommend it.

- Sherief

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

[Guilherme Balena Versiani]

Just to add more fuel to the fire, I rather like this idea too.

- Balena.


Sherief N. Farouk escreveu:

>> In OpenGL, you can create PBOs to store pixel data to read from and
>> write to
>> textures and render surfaces. It allows for fast access as calls like
>> glTexImage2D and co. can be scheduled to occur later and via DMA
>> transfers. It
>> also allows an app to map/unmap it to read and/or write quickly.
>>
>> Something like this could be useful to OpenAL too, I think. Often times
>> when
>> audio is decompressed, it requires the app to have a memory segment to
>> write
>> to and give to alBufferData. Since alBufferData needs to finish with
>> the user
>> pointer before returning, this would cause unnecessary waiting while
>> it's
>> copied and potentially converted. This would also be an issue for real-
>> time
>> generated streamed sounds.
>>
>>    
>
> I suggested this on the mailing list in March 2008, But it didn't make it
> through (You can check the thread, called "Faster buffer model, and more
> random stuff" for details of the discussion). Since then, I've implemented
> two revisions of this map/unmap buffer model (the latter more strongly
> worded than the former) and found it to be a bit faster (especially on
> in-order architectures) and it saved me having to use a proprietary
> extension on a gaming console, so I'd highly recommend it.
>
> - Sherief
>
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel
>  

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

[Chris Robinson-5]

Okay, here's a preliminary write up:

http://kcat.strangesoft.net/openal-extensions/EXT_sample_buffer_object.txt

The current GIT/SVN of OpenAL Soft has a working, in-progress, implementation
of it (no delayed scheduling; it's all done on-command, but the methodology is
there). Here's an app that will stream a .wav file by reading directly into
the databuffer and loading the buffers with it (it may require some tweaking
to compile on Windows):

http://kcat.strangesoft.net/wavstream.c

Any comments, questions, or requests are welcome.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Sherief N. Farouk]

"(eg. passing ((ALvoid*)2) to alBufferData will read sample data starting
    from the second byte of the selected databuffer)."

Don't you mean the THIRED byte? Passing 0 will read sample data starting
from the FIRST byte passing 1 will read sample data from the second byte,
and passing 2 will read data starting from the third byte.

- Sherief

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

[Erik Hofman]

Chris Robinson wrote:
> Okay, here's a preliminary write up:
>
> http://kcat.strangesoft.net/openal-extensions/EXT_sample_buffer_object.txt

How about Directbuffer instead of Databuffer?
It'll probably reflect the intentions a bit better.

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

[Chris Robinson-5]

On Sunday 16 August 2009 3:22:29 am Sherief N. Farouk wrote:
> "(eg. passing ((ALvoid*)2) to alBufferData will read sample data starting
>     from the second byte of the selected databuffer)."
>
> Don't you mean the THIRED byte? Passing 0 will read sample data starting
> from the FIRST byte passing 1 will read sample data from the second byte,
> and passing 2 will read data starting from the third byte.

Right, thanks. Was still thinking in terms of 0-based offsets...
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Sherief N. Farouk]

> Right, thanks. Was still thinking in terms of 0-based offsets...

Just like a true programmer :).

I found a typo: "Passing a NULL pointer for data is valid,l and will leave
the storage with
    undefined data." <-- there's an extra 'l' after the comma.

- Sherief

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

[Chris Robinson-5]

On Sunday 16 August 2009 10:19:15 am Sherief N. Farouk wrote:
> > Right, thanks. Was still thinking in terms of 0-based offsets...
>
> Just like a true programmer :).
>
> I found a typo: "Passing a NULL pointer for data is valid,l and will leave
> the storage with
>     undefined data." <-- there's an extra 'l' after the comma.

Fixed. I also added that calling alDatabufferDataEXT, alDatabufferSubDataEXT,
or alGetDatabufferSubDataEXT with a mapped databuffer is an
AL_INVALID_OPERATION (something the implementation already does, but I missed
noting it).
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Sunday 16 August 2009 5:19:36 am Erik Hofman wrote:
> How about Directbuffer instead of Databuffer?
> It'll probably reflect the intentions a bit better.

It's a bit longer, but it's not bad. Either could work I guess, so does anyone
else have an opinion?
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[E. Wing]

On 8/16/09, Chris Robinson <chris.kcat@...> wrote:
> On Sunday 16 August 2009 5:19:36 am Erik Hofman wrote:
>> How about Directbuffer instead of Databuffer?
>> It'll probably reflect the intentions a bit better.
>
> It's a bit longer, but it's not bad. Either could work I guess, so does
> anyone
> else have an opinion?


Conceptually, how do see this extension in comparison to the
alBufferDataStatic extension that Apple and Creative Labs/Xbox 360 (I
hear) support? If they overlap, perhaps their terminology needs to be
factored in?

Also, "DirectBuffer" worries me a little because it may imply things
about "faster performance" when I suspect that it may really depend on
the implementation. I know with SDL, a lot of newbies like to pick the
HW_SURFACE flag for their video surfaces thinking it will be faster
than SW_SURFACE, but enough time has passed that it is almost always
the case that SW_SURFACE is faster and better.

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

[Chris Robinson-5]

On Monday 17 August 2009 12:01:07 am E. Wing wrote:
> Conceptually, how do see this extension in comparison to the
> alBufferDataStatic extension that Apple and Creative Labs/Xbox 360 (I
> hear) support? If they overlap, perhaps their terminology needs to be
> factored in?

alBufferDataStatic lets the implementation/mixer use the app's data directly,
avoiding copies all together. Databuffers are simply OpenAL-controlled
storage, that in this extension in particular can be used for efficient
copying through alBufferData.

The latter leaves more flexibility with the OpenAL implementation since it can
continue using implementation-defined internal storage for Buffers (eg. always
convert to 16-bit, on dedicated hardware, etc), while buffer_data_static
requires the implementation to handle the data as-is.


I can also see databuffers being re-used for other things in the future.
Perhaps as a way to quickly update a number of sources' parameters, eg. one
buffer to hold a list of source IDs, and another buffer to hold property data,
then to send them and have it all update at once:

databuffer1:
ALuint = { sID1, sID2, sID4 }

databuffer2:
ALfloat = { xpos, ypos, zpos, gain,  xpos, ypos, zpos, gain,
            xpos, ypos, zpos, gain }

ALenum attribs[] = { AL_POSITION, AL_GAIN, 0 };

alSelectDatabufferEXT(AL_SOURCE_ID, databuffer1);
alSelectDatabufferEXT(AL_SOURCE_VALUES, databuffer2);

alMultiSourcefv(number_of_sIDs, (void*)0/*from source_id*/, attribs,
                (void*)0/*from source_values*/);

Then sources sID1, sID2, and sID4 would have their positions and gains updated
in one shot. The existing Playv/Stopv/Pausev/Rewindv functions could also work
with the AL_SOURCE_ID target.

But that was just an off-the-top-of-my-head idea. Would need some further
thinking to get it useful (particularly updating the listener at the same
time).
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel