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

[Chris Robinson]

On Monday 25 February 2008 06:31:51 pm Daniel Cocks wrote:
> 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 :)

More voices on the issue are always welcome. :)

> 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.

To an extent. I wouldn't be expecting a
alPlaySoundFile("my uber awesome song.mp3");
any time soon. ;)

OpenAL should make it easy to use the hardware. ALUT should make it easy to 
use OpenAL. eg:
alutInit(NULL,NULL);
ALuint buf = alutCreateBufferFromFile("my uber awesome song.mp3");
alGenSources(1, &src);
alSourcei(src, AL_BUFFER, buf);
alSourcePlay(src);

> 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.

ALUT doesn't completely "replace" AL. You still need to use OpenAL itself, but 
ALUT helps with initialization and sound file loading, etc. See above 
example.

> 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?

That's basically what's expected (granted OpenAL Soft does currently always 
realloc, but it wouldn't be hard to only realloc when more buffer space is 
needed).

> 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.

AFAIK, OpenAL is basically to DirectSound3D what OpenGL is to Direct3D.

> 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!

No apologies necessary. :)