Re: AUTimePitch -- edge artifacts
Re: AUTimePitch -- edge artifacts
- Subject: Re: AUTimePitch -- edge artifacts
- From: Chris Rogers <email@hidden>
- Date: Tue, 29 Nov 2005 13:08:12 -0800
On Nov 29, 2005, at 12:42 PM, Brian Whitman wrote:
Hi Chris,
Thanks for writing and I get that, but incrementing processIndex as
you describe does not work as it increments the synth buffer
position far beyond where it should, as per my previous mail. If I
incremented processIndex by the inNumberFrames every time, the next
time I render, the sample position would have "skipped" roughly
4000 samples.
No, it doesn't skip 4000 samples, since you gave it 12000 the time
before, you absolutely have to continue from where you left off. The
idea is very simple; the callback asks you for a specific
amount which you must provide. Then, the next time it calls you, you
need to give it samples at the point *exactly* where you left off the
last time.
If you're still having troubles after trying my suggestion then there
may be other issues as well, which you'll have to look at. But as a
starting point, you need to stop incrementing processIndex
after rendering each time, and instead increment it in the callback
function as I suggest.
The way I see it, and this is overly simplistic and might be the
cause of my trouble--
1) I need to render 8192 samples to play. I ask the AU to render
8192 samples, for which it needs to read the input 8192 samples
from my source buffer (at a stretch rate of 1.0).
This assumption is wrong, as you've noticed from (2) below. The
AudioUnit will read as many samples as it needs in order to generate
8192. Normally, it will call back multiple times
to read a total number of samples greater than 8192.
2) The AU actually reads roughly 12000 samples from the source
buffer but returns only 8192 rendered samples which represent the
first 8192 samples it got from the source buffer. I don't know what
it does with the other 4000.
3) The next time around, I need 8192 samples again. But I can't
tell the AU to start reading at position 12000 because I would have
skipped source buffer sample positions 8192->12000. At a rate of
1.0 I need the second time around to represent source buffer
position 8192-16384. Changing the code like you suggest confirms
this-- it's all stuttery at a rate of 1.0 if I increment the source
pointer by what the AU asks for.
Like I said before, you would not be skipping samples. There's a
processing latency involved, which you may not be taking into
account. This means it needs to read more samples initially
than the number of samples produced, even at a rate of 1.0! In
addition to the processing latency, the processing is using FFTs and
will tend to read in a "chunky" manner which is somewhat
out of step with what you're rendering on the output side, especially
for rates!=1.0. Don't assume anything about the number of samples it
will read based on how many you're rendering.
You have to keep the audio stream continuous at the input side.
There may be other issues at play here, but you've got to start
with that basic premise...
Chris Rogers
Core Audio
Apple Computer
_______________________________________________
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