Re: processing question
Re: processing question
- Subject: Re: processing question
- From: Brian Davies <email@hidden>
- Date: Sat, 6 Jun 2009 08:11:56 +1000
Thanks for that. It's actually a de-clicker I have in mind and the
user may want to treat only a selection of the file. The main
principle of declicking is that almost all audio samples are good and
must not be changed including not inserting or deleting anything.
Maybe I could set ProcessingInPlace to FALSE, and then pull samples
from the host which are beyond (in time) the samples being pulled from
my AU. That way, I would set L = T = 0. On the first pull by the
host, for B samples, I pull B+N samples, and return the B samples
unchanged. Next pull, I pull B samples, which are ahead of the host's
pull, and now I can return B treated samples. If I pull beyond the end
of the file I will zero-pad, which will work for my algorithms. That
way, I would not be at the mercy of the host to do the right thing
with L and T samples.
Can I use ProcessingInPlace in such a way?
Brian Davies
email@hidden
www.kagi.com/clickrepair
On 06/06/2009, at 5:58 AM, Brian Willoughby wrote:
On Jun 5, 2009, at 05:56, Brian Davies wrote:
Any help appreciated on the following:
How does an AU read ahead N samples ahead of its output (if it uses
an FFT-inverse FFT pair, for example) and not loose any of the data
at either end? ie, if the host wants samples from L to M
processed, in blocks of size B, the AU needs to read to at least L
+ B + N - 1 before it can output from L to L + B - 1, and so on,
right up to very last block which outputs to sample M. If the AU
is doing audio repair, and if it decides that NO repairs are
actually needed, it's important that the file being processed in
the host remains unchanged. Sending leading zeros, and throwing
away tails, will not cut it.
Your question implies that this is supposed to be addressed by the
AU alone, but the responsibility for the situation you describe is
shared with the host. The host must ask the AU for its latency (L)
and tail time (T), and then incorporate those numbers into its
processing of any file. In other words, the host must pull N + L +
T samples from the AU, feeding zero samples after the end of the
file has been passed. When saving the output of the AU, the host
will probably discard L samples at the beginning, and potentially
discard (T) samples at the end. However, it's not really safe to
discard samples on the tail, because the AU might be a reverb. The
exact situation you describe may require some human intervention to
decide whether to trim samples at the end of the output file. In
many situations, it's not that disastrous for a file to grow in
length when processed in the frequency domain. However, iTunes
seems to be able to handle this when converting CDDA to lossy
formats and back to CDDA when burning.
Brian Willoughby
Sound Consulting
_______________________________________________
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