Maximum Auxiliary Effect Slots

[Richard Rosario]

Greetings to you,
                          In my OpenAL implementation when I try to create Auxiliary Effect Slots only two are getting created and the third one fails returning error.

Is there any maximum limit to the number of Auxiliary Effect Slots.If that is so how do I get the maximum count.

Is the count based on per source basis or maximum for a device?

Thanks and Regards
Richard



_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Richard Rosario wrote:
>
> Greetings to you,
>                           In my OpenAL implementation when I try to
> create Auxiliary Effect Slots only two are getting created and the
> third one fails returning error.
>
> Is there any maximum limit to the number of Auxiliary Effect Slots.

Yes there is.


> If that is so how do I get the maximum count.

alcGetIntegerv(contextID, ALC_MAX_AUXILIARY_SENDS, &max);

(call this after creating your context)


>
> Is the count based on per source basis or maximum for a device?

It's a context property, but the value you get is a per-source maximum.

Look at the Effects Extension Guide in Creative's OpenAL SDK for better
descriptions and some sample code.

--"J"

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Jason Daly wrote:
>> If that is so how do I get the maximum count.
>>    
>
> alcGetIntegerv(contextID, ALC_MAX_AUXILIARY_SENDS, &max);
>
> (call this after creating your context)
>  

Sorry, that should be:

alcGetIntegerv(device, ALC_MAX_AUXILIARY_SENDS, 1, &max);

Note the extra parameter, and that you pass the device handle, not the
context ID.

Also, you can pass ALC_MAX_AUXILIARY_SENDS and a value as context
creation parameters to request a given maximum.  You still have to query
to see how many you actually get, though.

--"J"
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Tuesday 23 June 2009 9:40:17 pm Richard Rosario wrote:
> Greetings to you,
>                           In my OpenAL implementation when I try to create
> Auxiliary Effect Slots only two are getting created and the third one fails
> returning error.
>
> Is there any maximum limit to the number of Auxiliary Effect Slots.If that
> is so how do I get the maximum count.

Hi.

You get the maximum auxiliary slot count by seeing how many you can create..
similar to the max number of sources. The amount available depends on the
implementation/device.

> Is the count based on per source basis or maximum for a device?

The auxiliary slot count is the maximum for the device, AFAIK, however any
number of sources can feed a slot.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Tuesday 23 June 2009 10:33:06 pm Jason Daly wrote:

> Sorry, that should be:
>
> alcGetIntegerv(device, ALC_MAX_AUXILIARY_SENDS, 1, &max);
>
> Note the extra parameter, and that you pass the device handle, not the
> context ID.
>
> Also, you can pass ALC_MAX_AUXILIARY_SENDS and a value as context
> creation parameters to request a given maximum.  You still have to query
> to see how many you actually get, though.

That's actually for the number of sends, which is separate from the number of
slots. The number of sends is how many effects a source can have applied, and
the slots is the number of different simultaneous effects. For example, you
can have two distinct reverbs (2 slots), but a given source may only be able
to use one of them (1 send) while another source can use the other.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Richard Furse-2]

Hi there - does anyone know where the documentation for the
ALC_EXT_STATIC_BUFFER extension is? I can't find it in the repository. This
is the extension that documents alBufferDataStatic(). I'm wondering
particularly if it allows any special behaviour around buffer deletion...

Cheers,

--Richard


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Bob Aron]

Richard,

I'm not sure if there are other OpenAL implementations of the static buffer extension. As far as the Mac OSX implementation goes, it is important that the buffer memory NOT be deleted while still in use. In practice, that means that the same rules apply to static buffer objects as regular buffer objects. If calling alDeleteBuffers() is successful and produces no error, then it is safe to delete the buffer memory. The same goes for changing the data pointed to by the OpenAL Buffer object. If calling alBufferDataStatic (or alBufferData) is successful on a buffer object, then it is safe to delete your memory.

This extension is a very sharp knife in that if the application deletes the audio data memory while it is still  being used in the render chain, it is going to cause a crash.

-bob aron

____________________________________________

CoreAudio Team • Apple Inc.  

baron@...

On Jul 6, 2009, at 12:42 PM, Richard Furse wrote:

Hi there - does anyone know where the documentation for the
ALC_EXT_STATIC_BUFFER extension is? I can't find it in the repository. This
is the extension that documents alBufferDataStatic(). I'm wondering
particularly if it allows any special behaviour around buffer deletion...

Cheers,

--Richard


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Richard Furse-2]

Thanks - if I'm reading you right, this means you'll often reject the delete of a quick stop/unqueue/delete sequence because the audio engine hasn't actually finished working the audio. I guess you're setting AL_INVALID_OPERATION?

 

I'm glad to hear this, because this is exactly what I was wondering about doing for my OpenAL implementation :-)

 

With my Interface Police hat on, I'm still wondering if this is documented / the behaviour expected by game programmers?

 

Many thanks,

 

--Richard

---

From: Bob Aron [mailto:baron@...]
Sent: 09 July 2009 17:58
To: Richard Furse
Cc: openal-devel@...
Subject: Re: [Openal-devel] ALC_EXT_STATIC_BUFFER

Richard,

I'm not sure if there are other OpenAL implementations of the static buffer extension. As far as the Mac OSX implementation goes, it is important that the buffer memory NOT be deleted while still in use. In practice, that means that the same rules apply to static buffer objects as regular buffer objects. If calling alDeleteBuffers() is successful and produces no error, then it is safe to delete the buffer memory. The same goes for changing the data pointed to by the OpenAL Buffer object. If calling alBufferDataStatic (or alBufferData) is successful on a buffer object, then it is safe to delete your memory.

This extension is a very sharp knife in that if the application deletes the audio data memory while it is still  being used in the render chain, it is going to cause a crash.

-bob aron

____________________________________________

CoreAudio Team • Apple Inc.  

baron@...

On Jul 6, 2009, at 12:42 PM, Richard Furse wrote:

Hi there - does anyone know where the documentation for the
ALC_EXT_STATIC_BUFFER extension is? I can't find it in the repository. This
is the extension that documents alBufferDataStatic(). I'm wondering
particularly if it allows any special behaviour around buffer deletion...

Cheers,

--Richard


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Thursday 09 July 2009 12:08:49 pm Richard Furse wrote:
> Thanks - if I'm reading you right, this means you'll often reject the
> delete of a quick stop/unqueue/delete sequence because the audio engine
> hasn't actually finished working the audio.

This shouldn't be the case, as far as my understanding of OpenAL itself. By
the time the function call returns, the call should effectively be completed
so that any subsequent calls or use of data will not interfere with on-going
operations. For instance:

ALshort *data = new ALshort[numsamples];
alBufferData(bID, format, data, numsamples*2, freq);

in this case, you can immediately do anything with the data buffer after
alBufferData returns, from modifying to deleting, and OpenAL will not care.
Similarly:

alSourceUnqueueBuffers(sID, 1, &bID);
alBufferData(bID, format, data, numsamples*2, freq);

should work, assuming there is at least one processed buffer, because the
buffer returned to you should be unqueued by the time alBufferData does
anything. There is no reasonable way for the app to know the audio engine has
completed the request, so OpenAL needs to make sure the calls stay
synchronized.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Richard Furse-2]

Yep. This is what we do for alBufferData() - the issue is
alBufferDataStatic() - I was worrying about the guarantees expected here.
With alBufferData() the driver manages memory and so can do the cleanup at
the right time.

Of course, the same guarantee COULD be provided here too - but this
introduces an extra thread contention between the rendering thread and the
game thread which I'm trying to avoid. I'm trying to keep possible blocking
on the game thread (a) minimal and (b) predictable and handling
alBufferDataStatic() "synchronously" messes with that. I'm supporting
process/suspend properly too which makes this even more horrid...

(I'm actually still very unconvinced that alBufferDataStatic() is a good
idea at all, but people seem to want it so I'm checking it out...)

--Richard

> -----Original Message-----
> From: openal-devel-bounces@...
> [mailto:openal-devel-bounces@...] On
> Behalf Of Chris Robinson
> Sent: 09 July 2009 20:57
> To: openal-devel@...
> Subject: Re: [Openal-devel] ALC_EXT_STATIC_BUFFER
>
> On Thursday 09 July 2009 12:08:49 pm Richard Furse wrote:
> > Thanks - if I'm reading you right, this means you'll often
> reject the
> > delete of a quick stop/unqueue/delete sequence because the audio
> > engine hasn't actually finished working the audio.
>
> This shouldn't be the case, as far as my understanding of
> OpenAL itself. By the time the function call returns, the
> call should effectively be completed so that any subsequent
> calls or use of data will not interfere with on-going
> operations. For instance:
>
> ALshort *data = new ALshort[numsamples]; alBufferData(bID,
> format, data, numsamples*2, freq);
>
> in this case, you can immediately do anything with the data
> buffer after alBufferData returns, from modifying to
> deleting, and OpenAL will not care.
> Similarly:
>
> alSourceUnqueueBuffers(sID, 1, &bID);
> alBufferData(bID, format, data, numsamples*2, freq);
>
> should work, assuming there is at least one processed buffer,
> because the buffer returned to you should be unqueued by the
> time alBufferData does anything. There is no reasonable way
> for the app to know the audio engine has completed the
> request, so OpenAL needs to make sure the calls stay synchronized.
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel
>

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Bob Aron]

On Jul 9, 2009, at 12:57 PM, Chris Robinson wrote:

> On Thursday 09 July 2009 12:08:49 pm Richard Furse wrote:
>> Thanks - if I'm reading you right, this means you'll often reject the
>> delete of a quick stop/unqueue/delete sequence because the audio  
>> engine
>> hasn't actually finished working the audio.

>
> This shouldn't be the case, as far as my understanding of OpenAL  
> itself. By
> the time the function call returns, the call should effectively be  
> completed
> so that any subsequent calls or use of data will not interfere with  
> on-going
> operations. For instance:
>
> ALshort *data = new ALshort[numsamples];
> alBufferData(bID, format, data, numsamples*2, freq);
>
> in this case, you can immediately do anything with the data buffer  
> after
> alBufferData returns, from modifying to deleting, and OpenAL will  
> not care.

With alBufferData() this is true, because the implementation has  
copied the data into it's own buffers.
With alBufferDataStatic(), it is not true because the implementation  
may be referencing the data buffer provided by the client.
Before the client can delete the data buffer provided to  
alBufferDataStatic() , a successful (as in alGetError() returns no  
error) call to alDeleteBuffers(), alBufferData(), or alBufferDataStatic
() must be made. This lets the client know the implementation is not  
using the data because it allowed the OpenAL Buffer to be deleted or  
modified.

> Similarly:
>
> alSourceUnqueueBuffers(sID, 1, &bID);
> alBufferData(bID, format, data, numsamples*2, freq);
>
> should work, assuming there is at least one processed buffer,  
> because the
> buffer returned to you should be unqueued by the time alBufferData  
> does
> anything. There is no reasonable way for the app to know the audio  
> engine has
> completed the request, so OpenAL needs to make sure the calls stay
> synchronized.

In all the cases where the OpenAL implementation owns the resources  
(source, buffer, etc objects) this is true, because the implementation  
can decide when to dispose the objects.
Because the application owns the data buffer provided to  
alBufferDataStatic() this is not true. The 'reasonable' way for the  
app is to check the error after calling alDeleteBuffers(), alBufferData
(), or alBufferDataStatic() on a OpenAL Buffer that has been provided  
a static buffer.

-bob


> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Thursday 09 July 2009 1:19:30 pm Bob Aron wrote:

> With alBufferData() this is true, because the implementation has
> copied the data into it's own buffers.
> With alBufferDataStatic(), it is not true because the implementation
> may be referencing the data buffer provided by the client.
> Before the client can delete the data buffer provided to
> alBufferDataStatic() , a successful (as in alGetError() returns no
> error) call to alDeleteBuffers(), alBufferData(), or alBufferDataStatic
> () must be made. This lets the client know the implementation is not
> using the data because it allowed the OpenAL Buffer to be deleted or
> modified.

Yeah, sorry, I didn't mean to imply you can change/delete the data after
calling alBufferDataStatic, but rather, that when the OpenAL function returns,
the request should be completed as far as the user code is concerned. Eg. you
have a buffer set with alBufferDataStatic.. the buffer should be removed from
the source queue by the time alSourceUnqueueData returns and another
al*Buffer* call tries to work on it, and once alDeleteBuffers returns, the
buffer data pointer should be immediately free to be changed). The app
shouldn't have to do any waiting in between the calls.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel