[Openal-devel] OpenAL Soft 1.2.218 released

[Chris Robinson]

On Thursday 24 January 2008 12:08:57 pm Sherief N. Farouk wrote:
> >> Render-To-Buffer!!
> >
> >oh yeah, that would be great!
> >would it be with some timing control, or real time
> >only?
> >
> >(we have an option to shoot high quality game
> >replays to video files.
> >But so far, to add the sound track, you have to set
> >the recording device
> >to "loopback" - or whatever it's called, I don't
> >remember- and play the
> >sound and record back in real time. not very
> >elegant nor high quality...)
>
> It should be customizable, as in CGI rendering. A buffer of play length
> 1:00 can be rendered in real-time, or in as-fast-as-you-can mode (or as
> slow as you can, depending on the complexity on your DSP effects.)

Hmm, I think this should be doable (for OpenAL Soft, anyway). Something like:

ALCcontext *alcCreateRenderContext(ALsizei len, ALint *attribs);

With len being the length in frames of the buffer, and attribs being the 
standard context attribute list (including frequency, but would possibly also 
need a format specified). To use it, you'd need to set the context, create 
sources, etc, just like a normal context. Only difference is, it doesn't 
always run.. you'd call alcProcessContext and it fills up the buffer, then 
waits (automatically suspends). Bringing us to:

ALvoid alcMapRenderBuffer(ALvoid **mem, ALsizei *len);

Which would return a memory pointer and the amount of it renderer to, for you 
to read from or whatever. OIf course, given a typical ring buffer setup, this 
won't necessarilly give the entire buffer.. just from the last read point to 
the currently-rendering sample or the end of the buffer. Then:

ALvoid alcUnmapRenderBuffer(ALvoid *mem, ALsizei len);

Unmaps the memory pointer, and specifies how much memory was "processed". The 
unprocessed memory is left alone, but AL is free to start rendering to 
processed memory.


Or perhaps something a bit more double-bufferish:

ALCcontext *alcCreateRenderContext(ALsizei len, ALint *attribs);

Same as above.

ALCvoid alcSwapBuffers(ALCcontext *ctx);

Makes sure AL finishes rendering to the back-buffer (an implicit 
alcProcessContext), then sets it to the front. Following with:

ALCvoid alcRenderBufferRead(ALCcontext *ctx, ALenum format, ALsizei offset, 
ALsizei len, ALvoid *buf);

Reads from the front buffer, starting from the frame specified by offset up to 
len frames (offset+len must be equal-to or less-than the size specified when 
the context was created), converts it to the specified format, and writes it 
to the given memory pointer. Any unread data is destroyed on the next swap).

> Which brings up another point I'm working on: Custom DSP effects (Really
> custom, and not EFX style. Custom as in Coded-in-C-Like-Language).

Should be possible (biggest problem would be getting a C-like compiler with 
decent optimizations, and specifying the capabilities of the language). 
Vertex-shader like behavior could be calculating the source parameters from 
the source attributes (aluCalculateSourceParameters/CalcSourceParams in the 
Windows code/OpenAL-Soft), and pixel-shader shader like behaior would be 
reading from each source buffer and outputing what's mixed into the main 
buffers (both direct and room/effect buffers). Shouldn't be a problem to use 
a GL-like API for setting up the "shaders".


Of course, the biggest problem with both would be the viability of doing it in 
hardware and if Creative would implement it for their drivers.