• 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: Correct API to implement a timer in a real-time thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Correct API to implement a timer in a real-time thread


  • Subject: Re: Correct API to implement a timer in a real-time thread
  • From: Jeff Moore <email@hidden>
  • Date: Thu, 5 Jan 2006 12:08:08 -0800

The HAL uses the CAGuard class from the Public Utilities in the CoreAudio SDK to handle all it's scheduling needs. CAGuard simply wraps up a pthread mutex and cond var as a unit. CAGuard uses the function pthread_cond_timedwait_relative_np() to handle blocking the thread for a specified amount of time. If I remember right, the difference between this function and the pthread_cond_timedwait() is that in the former you pass the interval to wait and the latter you pass the time to wake up. The reason for this is purely because of the implementation of CAGuard. In fact, if you look at the implementation of pthreads in Darwin, you'll find that pthread_cond_timedwait() is implemented pretty much the same way that CAGuard::WaitUntil() is.

Anyway, the HAL gets it's drift-less timing from the way it handles calculating the next wake up time. The HAL takes advantage of the fact that it is always moving through time in same-sized chunks of sample frames. So, when it starts, it just makes an anchor time in sample frames. It also initializes a frame counter to 0. Then in each IO cycle, it increments the counter by the size of the IO cycle in frames. The HAL uses it's ability to map sample time into host time to figure out what absolute host time it needs to wake up next. From there, CAGuard handles things as I described above to block the thread and wake it at the specified host time.

I imagine that to implement a hard 1ms heart-beat, you'd probably want to do something similar, only the math is based on 1ms chunks as opposed to sample frames at a particular rate.

On Jan 5, 2006, at 6:16 AM, Stéphane Letz wrote:

If I use a CoreAudio task as a way to schedule my 1 millisecond interrupt, the nice thing is that CoreAudio seems to automically ajust/compensate timing deviations. I can have a serie of call that on average is 1000us. I would like to have timer API that allows to setup the same thing.


--

Jeff Moore
Core Audio
Apple


_______________________________________________ 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: Correct API to implement a timer in a real-time thread
      • From: Herbie Robinson <email@hidden>
References: 
 >Correct API to implement a timer in a real-time thread (From: Stéphane Letz <email@hidden>)
 >Re: Correct API to implement a timer in a real-time thread (From: philippe wicker <email@hidden>)
 >Re: Correct API to implement a timer in a real-time thread (From: Stéphane Letz <email@hidden>)

  • Prev by Date: Re: Correct API to implement a timer in a real-time thread
  • Next by Date: Getting parameter info on StereoMixers
  • Previous by thread: Re: Correct API to implement a timer in a real-time thread
  • Next by thread: Re: Correct API to implement a timer in a real-time thread
  • Index(es):
    • Date
    • Thread