Re: kAudioUnitProperty_InPlaceProcessing
Re: kAudioUnitProperty_InPlaceProcessing
- Subject: Re: kAudioUnitProperty_InPlaceProcessing
- From: William Stewart <email@hidden>
- Date: Thu, 4 Feb 2010 17:52:00 -0800
On Feb 3, 2010, at 7:58 PM, Paul Davis wrote:
> On Wed, Feb 3, 2010 at 9:59 PM, William Stewart <email@hidden> wrote:
>> An audio unit can process the samples provided in the input buffer (from
>> either a callback or a connection) and write the results of that processing
>> to that same input buffer (which will then get returned in its result of
>> AudioUnitRender)
>>
>> You can imagine a chain of effects that all process in place. The top of the
>> chain gets an input from say a render callback. Then it processes the audio
>> in that buffer, returns that to its caller, etc, on down the chain. So the
>> bottom of the chain (which is the AU that you called AudioUnitRender on)
>> will get returned (if you called audio unit render with mData ptrs in the
>> ABL set to NULL) the original buffer that was provided by the top's render
>> callback.... make sense?
>
> that all makes sense. however, does it also imply that if i were to
> ask an AU that does not support inplace processing to render, and i
> give it the same buffers for input and output, that i could expect
> some issues?
You can't do that.
The way this propagates is from input to output. To get the input buffer back, the ABL you pass to AudioUnitRender contains NULL as the mData ptrs (that allows the AU to pass a buffer to you, rather than copy into your buffer). When the AU renders, it will use its internal buffers for a callback, or NULL if it is a connection, to get its input.
If you do NOT support in-place, then the AU's mechanisms will provide an internal buffer to write the results of the prcoessing too, and your NULL ptrs are then referring to that internal buffer when AURender returns.
So, in other words, by supplying the NULL ptrs to AURender, you ensure that the correct thing will happen without having to manage this on a case by case basis.
Bill
>
> put slightly differently, does *lack *of inplace processing support
> imply that the plugin *cannot* use the same host-provided buffers for
> in+out, or does it just imply that the plugin will always give back
> its own buffers for output rather than use the host provided ones?
>
> --p
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden