Bad Bug in AUEffectBase
Bad Bug in AUEffectBase
- Subject: Bad Bug in AUEffectBase
- From: William Stewart <email@hidden>
- Date: Tue, 20 Jul 2004 18:16:49 -0700
The following two lines of code should be removed from AUEffectBase -
we will update the SDK to propagate this and some other fixes
previously mentioned shortly.
OSStatus AUEffectBase::ProcessBufferLists(AudioUnitRenderActionFlags
&ioActionFlags,
const AudioBufferList &inBuffer,
AudioBufferList &outBuffer,
UInt32 inFramesToProcess )
{
...
-> REMOVE -> outBuffer.mBuffers[0].mDataByteSize = inFramesToProcess *
channel * sizeof(Float32);
and
-> REMOVE -> destBuffer->mDataByteSize = inFramesToProcess *
sizeof(Float32);
...
}
Why?
The caller of AudioUnitRender is responsible for telling the AudioUnit
how much data should be generated- this is done both with the number of
frames as well as the data byte size of the buffers in the ABL passed
to AURender. The contract generally is that an AU should provide the
specified amount of data to the caller. (The one exception to this rule
is the final call to an offline AU - but that is not affected by this
bug).
ProcessBufferLists (PBL) can be called multiple times within one Render
call if there are parameter value changes that are scheduled within the
current AURender call - for instance, just before calling AURender you
called AudioUnitScheduleParameter with a non-zero buffer offset (this
is true for either immediate or ramped parameters) - setting the size
in this call ultimately means the the caller of
AudioUnitScheduleParameter can receive both an incomplete and
incorrectly marked ABL, as the AU has generated the appropriate data
but no longer signals that that is indeed the case.
Going Forward:
Initially the AUValidation tool will not fail AU's with this problem,
but will rather issue a stern warning.
Why? Any effect (including Apple's) that has shipped with this code
would fail validation. However, the call that it fails on is not in
regular use by host applications. Thus, in general and common usage the
bug is not exposed.
As AU's adopt ramped parameters and host's schedule parameter changes,
this bug will start to affect host apps in a very negative way. So, the
validation tool will provide an option to test an AU to see if it
passes this test correctly or not (when this option is presented the
validator would fail the AU with this bug). We'd strongly recommend
that AU's include this fix in their next release cycle.
At some point in the future we will release a version of the validation
tool that will fail any AU with this bug (including ours) - but that is
some time away as we wish to give everyone the time to revise their
implementations and not force a quick update cycle.
Thanks
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.