• 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 12:58:24 -0700


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


  • Follow-Ups:
    • Re: processing question
      • From: Brian Davies <email@hidden>
References: 
 >processing question (From: Brian Davies <email@hidden>)

  • Prev by Date: Re: Help on adding volume control
  • Next by Date: public.public.3gpp2 ?
  • Previous by thread: processing question
  • Next by thread: Re: processing question
  • Index(es):
    • Date
    • Thread