• 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
Question regarding recording and accounting for drift
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question regarding recording and accounting for drift


  • Subject: Question regarding recording and accounting for drift
  • From: Neil Clayton <email@hidden>
  • Date: Mon, 12 Jan 2009 17:06:36 +1300
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys

Hello all, and a happy new year!

I've written a bit code that can record from some device, to a QT Movie. It's using a couple of AU's, a home grown circular buffer and Audio Converter. It'll also let you playthru (much like CAPlayThough) if you're recording via Soundflower (or AudioReflectorDriver).

I'm seeing some drift. Probably not surprising since I've not accounted for it on the recording side.
I'd like to ask some more experienced developers if my current reasoning seems valid:


Diagram here:
http://dl.getdropbox.com/u/421935/Audio Recorder Design.pdf

This example shows recording from a 10ch device, playing through to a 2ch output (Speakers) and recording the 10ch discretely into QT. The dashed lines show my proposed change below.

The input / output flow is for plauthru.
The input / recorder flow is what I'm concentrating on.

Assuming that the circular buffer places data in "time" according to the timestamps received, if the input source were running slightly faster than the Audio Converter itself, would it be reasonable to assume that over time the audio would get ahead of the video (not shown)?

So would it therefore be reasonable to add another varispeed before the AC unit, as a way of controlling this? Would that be enough? The input/output rate of the varispeed and input rate of the AC would all match the nominal output rate of the Input HAL. I'd then account for drift using a method similar to what I've seen in CAPlayThrough (primarily because it's all I've got to go on).

Am I barking up the right tree?



Neil Clayton
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
  • Follow-Ups:
    • Re: Question regarding recording and accounting for drift
      • From: Brad Ford <email@hidden>
  • Prev by Date: Re: AUMIDIEffectBase Howto
  • Next by Date: Re: Curious happening with CAPlayThough
  • Previous by thread: Avoid annoying clicks/pops when start/stop audio unit generator
  • Next by thread: Re: Question regarding recording and accounting for drift
  • Index(es):
    • Date
    • Thread