Re: Quick question on configuring an AU for a certain channel config
Re: Quick question on configuring an AU for a certain channel config
- Subject: Re: Quick question on configuring an AU for a certain channel config
- From: William Stewart <email@hidden>
- Date: Tue, 11 Dec 2007 11:48:59 -0800
On Dec 11, 2007, at 12:18 AM, Bernd Burhoff wrote:
Hi,
very interesting thread, I'm trying to get sidechains to work too.
As far as I understand right now, to get access to audio from the
second input (bus 1) there are 2 ways :
AudioBufferList sidechainBufferList = theSidechainInput-
>GetBufferList();
or : float* scChannelPtr = theSidechainInput->GetChannelData(0);
In my AU this works both, when I process in mono with channel layout
{ 1, 1 }.
Now, when I test my channel layout for stereo { 2, 2 } something
strange happens:
The AudioBufferList tells me, that there are 2 buffers, as expected.
But when I access them both with
float* sidechainInputL =
(Float32*)sidechainBufferList.mBuffers[0].mData;
float* sidechainInputR =
(Float32*)sidechainBufferList.mBuffers[1].mData;
the second one ( Right ) does not contain audiodata. It seems like
it points to some wrong place.
When I use float* scChannelPtrL = theSidechainInput-
>GetChannelData(0);
float* scChannelPtrR = theSidechainInput->GetChannelData(1);
everything is fine and I hear the sidechain Input in stereo.
You can see the implementation of GetChannelData in AUScopeElement.h
and easily trace through.
Does anybody know how that ? Is GetChannelData(n) the prefered way ?
That's how we do it.
Another thing, that I do not realy understand is that my AU passes
auval test, and it works fine in logic8, but auval gives me a
warning :
WARNING: AU Reports Processing in Place; Input buffer[0]:0xcf000 and
Output buffer[0]:0xc7000 are not the same
In some cases your AU is not really processing in place - the input
buffer that was given to your AU's input, was not the buffer that it
returned from the Render call.
My guess is that (particularly given side chains) that you are copying
your processing and returning that as your output (or some variation
on this theme) - I can't tell without a detailed examination of your
code (which I'm not going to do! :)
Unless you are able to process the samples in place (that is, process
them and push them back into the same buffer you were given from
input), then you should make sure that you don't support this property.
AUEffectBase is a convenient jumping off point for many effects, but
the simplicity of the implementation it does also means that it is
inappropriate for some effects that have more constraints on the kinds
of work they can do. So, you'll need to dig into the code in
AUEffectBase and have a better understanding of what it is doing, and
what is inappropriate for it do for you. There have been various posts
on this list in the past that have detailed some of the refactoring
you might have to do.
Bill
_______________________________________________
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