Re: Opinions sought: AudioUnit Rendering
Re: Opinions sought: AudioUnit Rendering
- Subject: Re: Opinions sought: AudioUnit Rendering
- From: Doug Wyatt <email@hidden>
- Date: Tue, 5 Mar 2002 21:38:02 -0800
That won't quite do it. What's needed as a way for the caller of
RenderSlice to get a value back saying that the buffer it returned is
silent. So we'd have to have another version of RenderSlice, and then
we'd have to deal with the implications of callers knowing whether they
can call RenderSlice2 vs. RenderSlice, and some similar code in each AU
(though factored down into AUBase) to implement both RenderSlice and
RenderSlice2.
The reason Bill suggested that an AU's RenderSlice could zero the
supplied buffer's mNumberChannels or mDataByteSize -- while still
outputting an mData buffer of zeroes -- is that, in looking through our
own AudioUnits, everyone who calls RenderSlice does not currently look
at these fields of the AudioBuffer on return, with only one or two
unusual exceptions. Most callers don't care what the source unit did to
those fields because the API doesn't specify what the effect of the
source unit altering them would be. And those that do would break if
callers were doing unusual things to those fields, which they
shouldn't. So those exceptional AU's who look at
AudioBuffer.mNumberChannels and/or AudioBuffer.mDataByteSize after
RenderSlice (PullInput) are easily changed because they are setting
those fields before calling RenderSlice, so it can certainly use the
previous values instead of fetching them back out of the AudioBuffer.
So the only way this is non-backwardly compatible is with AU's that rely
on the caller not to modify the field, which is a meaningless thing it
to have done.
There are definitely pros and cons to both approaches. Adding
RenderSlice2 means that using the API gets more complex for both client
and AU writer, but has no compatibility issues other than the danger of
people getting confused about having to implement both RenderSlice and
RenderSlice2. Documenting that RenderSlice may only alter the
AudioBuffer in one particular way with one particular meaning might
break a very small number of AudioUnits, but they'd be easily fixed and
the API wouldn't be significantly more complex.
A good data point would be: how many of you have audio units that,
after calling PullInput / RenderSlice, look at any fields of the buffer
other than mData? They're the only AU's that would break.
Thanks for the input; we'll keep pondering this.
Doug
On Tuesday, March 5, 2002, at 07:45 , Laurent de Segur wrote:
How about adding a new audio unit selector
(kAudioUnitProperty_SetInputCallback2 or a better name) which would let
you register a callback proc with the AudioUnitRenderActionFlags being
passed as a pointer so you can now pass and get back states in it?
What I believe you will gain with this approach:
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
"Don't negate, create."
-- dsw
_______________________________________________
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.