Re: Buffer Size in Audio Units
Re: Buffer Size in Audio Units
- Subject: Re: Buffer Size in Audio Units
- From: Stephen Blinkhorn <email@hidden>
- Date: Thu, 29 Nov 2007 00:05:50 +0000
right, turns out my AU was being re-initialised with the new
MaxFramesPerSlice value set correctly, although I did want to clarify
that I was doing things the proper way. But, the console log doesn't
seem to get updated until you quit and reopen AULab. This is on
Leopard. On 10.4 I could post diagnostics and see instantly what was
going on in my AU. Anyone else seeing this behaviour? Maybe i've
gone off-topic a bit now and hi-jacked a thread in the process..
cheers, Stephen
// audiospillage.com
On 28 Nov 2007, at 20:30, Brian Willoughby wrote:
To be precise, nothing happens when the host changes the block size,
other than a parameter changing in the Process(inFramesToProcess) or
Render(nFrames). You must track this parameter independently for
each render call. The host need not change the max frames unless
the current block size would exceed an existing max frames. In
other words, there is a distinct difference between max frames and
current frames.
You probably don't want to use the max frames for your FFT size,
unless you don't care about latency. Max frames is really intended
to allow you to allocate enough memory to handle the largest block
that might come your way.
To be honest, though, I don't know whether AULab ties the user block
size to max frames. It may or may not.
Brian Willoughby
Sound Consulting
On Nov 28, 2007, at 08:03, Stephen Blinkhorn wrote:
I'm slightly confused.. I am using the AUBase::GetMaxFramesPerSlice
in my Initialize method. But, what happens when the host changes
the block size? I'm using AULab to test my AU but nothing seems to
happen unless the AU is completely relaunched. Out of curiosity,
does the CoreAudio/AudioUnit specification impose an upper limit on
block size for a host application?
cheers, Stephen
_______________________________________________
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