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: William Stewart <email@hidden>
- Date: Tue, 05 Feb 2013 14:01:05 -0800
On Feb 5, 2013, at 10:41 AM, Kyle Sluder <email@hidden> wrote:
> On Feb 5, 2013, at 10:25 AM, James McCartney <email@hidden> wrote:
>
>> 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.
>
> I understand that this ultimate solution is superior. But I have still have a question about the interim solution: is it possible to derive the requisite buffer size from some property exposed by the audio unit? For example, is it a known function of the _Latency property and the sample format?
No, its not. So, the recommendation is that if you are planning on doing this "unsupported" methodology because you want to get the pitch change, then we "think" that the way this can work is to do what we have said.
However, the basic advice at this point is that you should not be using format converter AU types in an AQTap. (The reason being that a format converter can require more input samples (or less) than its output, but the AQTap is essentially a "real-time" model).
Thanks
Bill
>
> Thanks for the info,
> --Kyle Sluder
_______________________________________________
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