Re: AUTimePitch -- edge artifacts
Re: AUTimePitch -- edge artifacts
- Subject: Re: AUTimePitch -- edge artifacts
- From: Brian Whitman <email@hidden>
- Date: Tue, 29 Nov 2005 15:42:20 -0500
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.
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).
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.
On Nov 29, 2005, at 2:46 PM, Chris Rogers wrote:
Brian,
I think the problem is simply that you must provide a *continuous*
uninterrupted clean, glitch-free input to AUTimePitch.
It's time-stretching exactly what you're giving it, which is an
input, read from your wave buffer, which has a glitch every time
you abruptly change your index "def->processIndex" causing a break
in the waveform. I think you need to properly advance def-
>processIndex by the
inNumberFrames argument in memoryBufferCallback() (do this in that
function right before you return).
Chris Rogers
Core Audio
Apple Computer
On Nov 29, 2005, at 7:56 AM, Brian Whitman wrote:
Before I go insane listening to clicks all day, I put my code
(based on the Sinewave sample) up on my site for anyone who'd like
to try it out and tell me my problem.
http://variogr.am/Sinewave_AUTimePitch.zip
The sound that loops is in the bundle there. At a rate of 1.0 (no
stretch) the clicks are every 8192 samples, which is my buffer
length (where the Render call starts every time.) If someone could
exorcise those or educate me a bit more on how offline AUs are
supposed to be called I'd appreciate it. When it's fixed I'll post
the final result again for others' sake.
Thanks
Brian
On Nov 28, 2005, at 7:16 PM, Brian Whitman wrote:
Hi Chris, I see that the callback might get called multiple times
per render and goes over what you ask for.
Ignoring stretching (say the stretch was at 1.0) -- in my
example, I looked at the first callback and saw that it starts at
synth buffer position 0 and asks for 11920 samples total during
the render when I ask it to analyse 8192 samples.
But I can't then increase my synth buffer pointer by 11920
samples-- the next time I ask for 8192 samples I want those
samples to be read starting at synth buffer pointer 8192 as the
returned rendered data represents only 8192 samples.
So that was the purpose of "askFor"-- to advance the starting
position within the synth buffer every time I ask for more
samples. Internal to the AU callback, the mSampleTime takes care
of sample position within the analysis buffer.
I have a feeling I'm missing something obvious here though. I'll
keep playing with my pointers.
Brian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
--
Brian Whitman. http://variogr.am/
The Echo Nest Corporation
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