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

[Jason Daly]

Hi, all,

I've been away for a while, and I'm kind of jumping in the middle here, 
but I thought I'd add my $0.02...


Chris Robinson wrote:
> On Monday 25 February 2008 07:38:17 pm Sherief N. Farouk wrote:
>   
>>>> : I was speaking about a new API from the start.
>>>>         
>
> I'd think any new AL API should be designed after GL3. Unfortunately the 
> Khronos group is taking their sweet time with it, and no one really know what 
> it's like yet.
>
>   

While it's a good idea to mirror the look and feel of OpenGL, there has 
to be a point where you step back and make sure that what you're doing 
makes sense for audio and for developers.  OpenGL 3 has a specific 
purpose, to eliminate the cruft that's been left over the 10 or so years 
that OpenGL has been around.  Graphics cards (and graphics itself) has 
changed a lot and OpenGL has maintained backward compatibility.  While 
this is nice for apps written 10 years ago, it's murder on the driver 
writers, so this kind of change makes sense.

OpenAL hasn't changed much either, but there hasn't been nearly as much 
change in the state of the art in audio (yet), so do we really need to 
track OpenGL 3 and mirror it's new API's just because it's there?

I don't think it's a good idea, for example, to bring up a new immutable 
buffer creation API just because OpenGL 3 is now introducing immutable 
texture objects.  If an immutable buffer API makes sense for game audio 
developers, then great, let's do it.


Another side to this is the whole issue of memory and the two copies of 
audio data.  First, I'll say I'm not a game audio developer.  I'm a 
visual simulations developer, and I tend to get all the hardware I want 
when I write code.  I also had trouble following the discussion (mainly 
I had trouble picking out Shereif's comments from the quoted stuff), so 
I apologize if I missed any points.  That said, it seems to me that 
while the duplication of data is indeed a pain for developers on 
resource-limited platforms, I'd think an API that may or may not 
allocate temporary memory depending on certain circumstances would be 
even worse.  What a developer wants most of all is control, and anything 
that takes that control away from him/her makes the API less useful.  
Finally, I don't think it's saying too much to say that Creative is 
working on addressing some of these issues, and to suggest that we wait 
for Creative to officially weigh in before doing anything concrete.  
After all, I think they have more contact with developers than any of us.


There, my $0.02.  Let the battle resume...  ;-)

-- 

--"J"

"I'm a castaway stranded in a desolate land,
 I can see the footprints in the virtual sand."
	--Neil Peart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal-devel/attachments/20080226/f2fff33e/attachment.html