• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: processing question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: processing question


  • Subject: Re: processing question
  • From: Brian Willoughby <email@hidden>
  • Date: Fri, 5 Jun 2009 16:05:46 -0700


On Jun 5, 2009, at 15:11, Brian Davies wrote:
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.


One simple thing that I forgot to mention is that the host has total control over whether samples are inserted or deleted. An AU is required to produce the same number of sample frames on output as on input. More precisely, in the pull-model that CoreAudio uses, an AU will be asked to generate a specific number of output samples, and it should pull that same number of samples from any inputs that it might have. There are a few exceptions for sample rate conversion AudioUnits, but the above is the general rule.

When writing an AU, you should never insert or delete any samples. The host will be responsible for the latency lead time and the tail time. What you're discussing is still a challenge, but it's a challenge for the host to deal with. It would be nice to see more discussion of these issues, though.

To return to your original example of an FFT+iFFT AU, the AU is responsible for buffering enough samples to fill the FFT window. But at no time can the AU consume fewer samples than the host requests. Therefore, despite the temptation to run a 1024-point FFT directly from 1024-sample buffers, an AU can never really rely on the host always calling for full buffers, so the AU must use its own internal buffers and report the resulting latency to the host. Because of this requirement, an AU host should always call an AU with a few extra samples after the end of a file, at least enough to pad out the latency and tail time. If a host fails to do this, then the final FFT buffer inside an AU may never be processed, because it could still be waiting for one or more samples before it can complete a window.

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


References: 
 >processing question (From: Brian Davies <email@hidden>)
 >Re: processing question (From: Brian Willoughby <email@hidden>)
 >Re: processing question (From: Brian Davies <email@hidden>)

  • Prev by Date: Re: processing question
  • Next by Date: Re: processing question
  • Previous by thread: Re: processing question
  • Next by thread: Re: Processing question
  • Index(es):
    • Date
    • Thread