Re: clocks
Re: clocks
- Subject: Re: clocks
- From: Jeff Moore <email@hidden>
- Date: Mon, 17 Nov 2008 11:35:48 -0800
There are many factors that go into building a clock in the way you'd
like to do. But the basic algorithm for the most efficient and
accurate way to create one goes something like this:
1) Create a thread.
2) Calculate when the next call out needs to be issued
3) Make the thread sleep until the wake time
4) When the thread wakes, do the call out
5) Goto step 2
I realize that you say that you are "looking for something more
accurate than a thread in a sleep/execute loop" and I outlined just
such an algorithm. Presumably by "accurate", you mean to minimize the
amount of latency between the ideal time for the callout and the
actual time the call out takes place (which I often refer to as
scheduling latency).
At any rate, there is no better algorithm than this. The scheduling
latency you get with this kind of algorithm depends directly on the
priority of the thread you are using as well as the amount of overhead
in your code to get from the thread waking up to the call out. This
algorithm has the advantage in that you can drive it with the best
clock on the system, mach_absolute_time. It also has the advantage of
being code-able in pretty much all the languages you specified.
Just so you get where I'm coming from on this, the HAL's IO thread is
a very time critical thread that needs as little scheduling latency as
possible. Indeed, this is the thread whose job it is to call an app's
IOProc to deliver input data and pull output data to deliver to the
device. It is very much a deadline driven thread that is very
sensitive to scheduling latency.
Given all that, the HAL's IO thread still uses this very algorithm to
do it's scheduling. It just takes all the sensible precautions it can
to ensure that it's scheduling latency is low. For example, the work
the HAL needs to do between waking up and calling an app's IOProc is
purposefully kept small. Further, the IO thread uses the time
constraint policy the scheduler provides. This makes the thread run at
nearly the highest priority on the system which ensures as little
scheduling latency as possible. Finally, the thread uses
mach_absolute_time as it's time base and
pthread_cond_timedwait_relative_np() as the call to wake the thread up
at a particular time.
On Nov 17, 2008, at 6:53 AM, Sam Aaron wrote:
Hi there,
I have a dream involving clocks; I can't really talk to my wife
about it as her eyes tend to glaze over pretty quicksmart...
However, this list might provide a more appropriate audience,
particularly as I need a little bootstrapping help to get things
started. My goals are as follows:
* Have one strongly-timed clock that beats very accurately and calls
a particular method on clock ticks. (I'm looking for something more
accurate than a thread in a sleep/execute loop).
That's it really.
Now, of course, dreams have no bounds, and eventually I would like
to do the following:
* Be able to change the tempo of ticks on the fly (speed it up and
slow it down at whim),
* Have similar, concurrent, clocks that are related in tempo by a
function (i.e. twice as fast, 1/3 the speed etc.),
* Have the method that is called by a particular clock be able to
read a buffer of midi/osc packets in reasonable speed,
* Have the method that is called by a particular clock be able to
send midi/osc packets as quickly as possible.
And for the really wild stuff...
* Be able to program it in Ruby (or MacRuby, or in JRuby on the JVM)
without affecting performance.
Now, I understand that not all of this may be possible (particularly
the last goal) however, I'd like to see how far I can get. I just
need some initial directions. For example, the following are
possible options:
* code all this in C with core audio clocks and wrap it in Ruby via
a foreign function interface,
* write it in objective-c and have it as a stand alone module..
* write it in java calling out to core audio clocks, and call the
java from jruby..
* use macruby and get the best of all worlds..
I am very interested in any advice/hints/pointers on which route I
should take with this project.
Thanks in advance,
Sam Aaron
_______________________________________________
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
--
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
| References: | |
| | >clocks (From: Sam Aaron <email@hidden>) |