[Openal] OpenAL 1.1 (OS X) alGenBuffers problem

[Edmund Zavada]

Thanks for the reply Garin. My app does not care what the buffer  
number is, it just treats it as a transparent "ptr" and passes it  
back in to the OpenAL calls. The behavior on Windows is to return  
random buffers, and the app works fine with that.

I understand that the value 2400 might simply be an arbitrary offset  
applied to sequential buffer numbers, or even something else  
entirely. My concern is that this is actually a sequential buffer  
number, and that there are 2400 buffer already allocated somehow (not  
deliberately by my app).

I would never even bother to worry about it if it weren't for that  
fact that time profiling the running app shows OpenAL consuming a  
huge amount of CPU iterating an rb tree. (I'm using Shark, which  
doesn't require a special profiled build -- this is somewhat like  
strace on Linux only it profiles the entire app, not just system calls).

Here's the output from Shark, using a bottom up view of the call tree:

	67.9%	67.9%	OpenAL	std::_Rb_tree_base_iterator::_M_increment()	
	0.0%	67.7%	OpenAL		OALSourceMap::GetSourceByIndex(unsigned long)	
	0.0%	34.2%	OpenAL			OALContext::RemoveSource(unsigned)	
	0.0%	34.2%	OpenAL				alDeleteSources	
	0.0%	34.2%	ww						audio_stop(int)	
	0.0%	33.6%	OpenAL			OALContext::AddSource(unsigned)	
	0.0%	33.6%	OpenAL				alGenSources	
	0.0%	33.6%	ww						audio_playasset(int, int, t_audioasset*)	
	0.0%	0.1%	OpenAL		OALContext::CleanUpDeadSourceList()	
	0.0%	0.0%	OpenAL		OALContext::SetListenerVelocity(float, float, float)	

So what this is saying is that my app's two audio functions are  
taking nearly 68% of the CPU time (audio_stop() - 34.2% and  
audio_playasset() - 33.6%). But all that time is actually spent  
inside OpenAL, ultimately in the same call,  
OALSourceMap::GetSourceByIndex(), which in turn is spending all it's  
time calling std::_RB_tree_base_iterator::_M_increment().

It seems to me that either the standard iterator is very inefficient  
(the app is compiled with gcc 4.0.1 apple-powerpc-darwin), or that  
there are a lot of buffers being iterated. It's also possible I  
suppose that the logic is just wrong somewhere, resulting in too many  
calls to OAL::GetSourceByIndex()

BTW, the buffer numbers are largely sequential: 2401, 2403, 2404,  
2405, 2406, 2407, 2408, 2409, 2411, 2413, 2414, etc...

By contrast, when running under the 1.0.6 (which I believe you built,  
Garin), OpenAL as a whole barely even registers in the CPU sample:

	0.1%	0.1%	OpenAL		alDeleteSources	
	0.0%	0.0%	SDL			SDL_GetTicks	
	0.0%	0.1%	ww				audio_stop(int)	
	0.0%	0.0%	OpenAL		alGenSources	
	0.0%	0.0%	ww				audio_playasset(int, int, t_audioasset*)	

Looking more closely at this, it seems that alDeleteSources is not  
using a RB tree in the 1.0.6 implementation.

Best Regards,
Ed


On Dec 13, 2006, at 1:03 AM, Garin Hiebert wrote:

>
>>  it seems that the first call I make to alGenBuffers(1, &buf) is  
>> returning a value of 2401, whereas in 1.0.6 it used to return 1 as  
>> the buffer number.
>
> This may not result in a solution to the problem, but why does it  
> matter to your app (or does it?) what value "buf" is being set to?   
> It's just a number, and your app shouldn't be dependent on buffer  
> or source IDs being allocated in any particular way.  In other  
> words, the ID allocation scheme for both buffers and sources is  
> entirely arbitrary -- if the first buffer ID came back 16172, the  
> second 4379, the third 8254, and any others also seemed "random"  
> your app shouldn't care.
>
> Garin
>