[Openal-devel] Faster buffer model, and more random stuff

[Daniel Cocks]

First of all I'd like to say sorry for jumping into a middle of a
discussion that quite simply, I don't understand thoroughly. I hope I
don't sound too confused :)

>From what I can see, the changes that Sherief Farouk is proposing are
motivated by a desire to optimise the memory interaction of a program
and openal. Correct me if I'm wrong but these points seem to be the
goal:

a) Provide more information on buffer creation so an implementation can
optimise creation ready for filling the buffer.
b) Allow a method of using a buffer's memory directly from the program
without storing temporarily in the program (e.g. when reading from a
file)
c) Prevent unnecessary deallocs and reallocs occuring in the openal
implementation.

My comments:

First comment I want to make is that I feel that the openal API (not the
implementation or extensions available) should always accommodate to the
lowest common denominator in programmer. If it can be possible to start
a sound playing in a few lines without having programmed in sound before
or understanding details of formats, then the API should provide this.
After all, it was the simplicity of openal that got me into it in the
first place.

And I do mean a few lines of openAL, not Alut - while I love to use
toolkits like alut and glut for small specifc tasks, using Alut
completely and never touching a line of openal code seems
counterintuitive to me. Advanced buffering techniques, etc... might be
best implemented and made available via extensions and perhaps hints
given to the objects, although I'm not sure if this would be too
unwieldy.

Onto the rest:

a) Having to provide a stack of information (say 10 arguments) in an
object creation is not something I have liked in other APIs. Providing
two options - the current buffer creation function with state based
changes (which may be implemented as merely holding a booking for a
future 'proper' creation) as well as a 'the-works' buffer creation
function might be a solution.

b) I don't see, with the conversion between formats and the possibility
of not knowing an internal format, how this can be done. I think I don't
understand the term 'convert-on-read'. If the mapping is not a direct
mapping then how can it be saving memory? Won't two copies of the data
still need to be stored?

c) As far as I can imagine, it would be a very unlikely situation for a
buffer to be continually changing size and needing a realloc. Shouldn't
the implementation assume that the buffer size will not likely change,
and so only dealloc or realloc when given larger data than it can hold?

The last thing I want to ask is for what purpose has openal been
designed... do the openal implementations work well on resource-limited
devices? As I thought that 99% of openal use was on resource-rich modern
computers, I don't feel that the essential parts of the API should be
made more complicated.

This was meant to be a quick comment... looks like I got carried away.
Sorry if I've said anything stupid - it's only through ignorance!

Cheers,
Danny

On Mon, 2008-02-25 at 17:33 -0800, Chris Robinson wrote:

....