Re: AudioQueueProcessingTap broken in 6.1? (was: Re: NewTimePitch Audio Unit Distorts Signal)
Re: AudioQueueProcessingTap broken in 6.1? (was: Re: NewTimePitch Audio Unit Distorts Signal)
- Subject: Re: AudioQueueProcessingTap broken in 6.1? (was: Re: NewTimePitch Audio Unit Distorts Signal)
- From: James McCartney <email@hidden>
- Date: Tue, 05 Feb 2013 10:25:36 -0800
On Feb 5, 2013, at 8:26 AM, Kyle Sluder <email@hidden> wrote:
> On Mon, Feb 4, 2013, at 06:11 PM, William Stewart wrote:
>> There are a couple of things to note:
>>
>> For this example, one way you might be able to get it to work is to add
>> the following:
>> (1) Add an intermediary buffer of (we think 4k samples is enough)
>> - in the AURemoteIO, you would cache 4K samples of input (so the first 4k samples you provide for the output is silence)
>> - in the AQTap, you cache the first 4k samples you get from the tap, and push 4k samples of silence into the graph.
>> (2) As long as you do NOT change the rate, we think this number of
>> samples should be sufficient
>
> Forgive me for my inexperience, but if one avoids performing SRC within
> the audio queue tap, why must one then introduce a buffer at all?
AUNewTimePitch is a format converter. Internally it is doing overlapped FFTs, so it pulls to get the data it needs. The extra buffer is to satisfy this extra pulling. Ultimately the answer is for us to release an AUNewPitch that is an effect. Same algorithm but since rate is not a parameter, the upstream pull size can be guaranteed to match the amount pulled for.
James McCartney
Apple CoreAudio
email@hidden
_______________________________________________
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