Re: Opinions sought: AudioUnit Rendering
Re: Opinions sought: AudioUnit Rendering
- Subject: Re: Opinions sought: AudioUnit Rendering
- From: Bill Stewart <email@hidden>
- Date: Wed, 06 Mar 2002 19:33:38 -0800
I don't think we're that interested in the partial buffer case. The real win
here is that in the case of a reverb for instance, its going to do a lot of
processing of data before its tail is really below a minimum threshold. So
the partial buffer provides little I think in comparison to that.
But if the reverb can know that it has no valid input since time x, and its
done its tail it can then just pass a silent buffer through or NULL, or
whatever we decide.
The parital buffer stuff is really tweaky and I think Laurent's earlier
comment about the overloaded tweakiness of some APIs can eventually make
them unusable - we're trying to avoid that situation as well.
Bill
on 6/3/02 3:26 PM, Kurt Bigler wrote:
>
on 3/6/02 6:57 AM, Doug Wyatt <email@hidden> wrote:
>
>
> This is a very promising idea -- we could have AudioToolbox export two
>
> globals:
>
>
>
> extern const Float32 *kAudioToolbox_SilentBuffer;
>
> extern const UInt32 kAudioToolbox_SilentBufferNumberSamples; // number of
>
> samples in kAudioToolbox_SilentBuffer
>
>
>
> and AudioUnits' RenderSlice methods would be free to compare incoming
>
> AudioBuffer.mData's against it, and set outgoing mData's to it (as long
>
> as they were outputting fewer than
>
> kAudioToolbox_SilentBufferNumberSamples). Totally backward-compatible,
>
> a minimal API addition, and allows a good optimization.
>
>
>
> Thanks!
>
>
>
> Doug
>
>
>
If it is worth representing the partial-buffer-silent case, then maybe it is
>
worth representing a buffer that is partially silent at either end.
>
Otherwise the effort to represent partial silence only helps you in half the
>
cases that the concept is capable of.
>
>
Consider the case when one signal path goes silent just as another comes on.
>
If you represent partial silence at either end of the buffer then it would
>
be possible to make that transition with a minimal spike in the CPU load.
>
It is the spikes that make or break a system sometimes. Even if there is
>
some overlap in the transition this approach will minimize the CPU spike.
>
>
One possible representation:
>
>
extern const UInt32 kAudioToolbox_SilentBufferNumberSampAtBeg;//#silent @beg
>
extern const UInt32 kAudioToolbox_SilentBufferNumberSampAtEnd;//#silent @end
>
>
Silence at both ends (but not the middle) of a buffer is probably not worth
>
worrying about, but allowing it kind of falls out of the above
>
representation, which is probably an easier-to-use representation than to
>
have a flag specifying whether silence is at the beginning or the end.
>
>
-Kurt Bigler
>
_______________________________________________
>
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.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
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.