Re: Processing question
Re: Processing question
- Subject: Re: Processing question
- From: Brian Davies <email@hidden>
- Date: Tue, 9 Jun 2009 18:08:44 +1000
ProcessingInPlace is not exactly related to the concepts you're
dealing with. ProcessingInPlace merely controls a minor detail of
buffering -
Yes, I asked the wrong question. What I really had in mind is the
possibility to override
ComponentResult AUEffectBase::Render( AudioUnitRenderActionFlags
&ioActionFlags,
const AudioTimeStamp & inTimeStamp,
UInt32 nFrames)
{
.
.
.
AUInputElement *theInput = GetInput(0);
result = theInput->PullInput(ioActionFlags, inTimeStamp, 0 /* element
*/, nFrames);
if (result == noErr)
{
.
.
.
which commences by pulling nFrames from the theInput. My proposal was
to pull frames ahead of the current Render request (might involve
several invocations of theInput->PullInput since the size of theInput
buffer is out of my control), copying to a large internal ring buffer
(the accounting will be dynamic because of the mismatch of buffer
sizes), move my processing forward nFrames in the ring buffer, then
output precisely nFrames as requested. Hence, with L = T = 0, then
host doesn't need to know anything, and I don't need to make
assumptions about the host. Will this play well or badly with the AU
framework?
Brian Davies
_______________________________________________
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