Re: Threading/timer issues on Mach-O vs. OS 9
Re: Threading/timer issues on Mach-O vs. OS 9
- Subject: Re: Threading/timer issues on Mach-O vs. OS 9
- From: "James Chandler Jr" <email@hidden>
- Date: Mon, 24 Apr 2006 10:18:15 -0400
This is inexpert advice, since I don't keep modern with OSX. It changes too fast
for my tastes. Too fast a moving target.
I was using a 1 ms Timer on Mac MIDI since before they invented the Time
Manager. You had to manually patch the (as best I recall) level 2 interrupt
table before the Time Manager was invented.
Anyway, I kept using the timer task on the OSX port, and it seems to work OK.
From long habit, you just don't wanna do any more work than absolutely necessary
in a timer task (or timing thread).
You don't mention whether you actually derive your Tick Timebase by counting
timer tasks. On some OS's or slow computers, you can't always rely on the
'timeliness' of Timers for steady playback.
But if the Timer callbacks (of whatever flavor) are not ridiculously sloppy, I
find you can get 'perceptually solid feeling' playback timing by using some
other mechanism to find out what time it is every time you wake up in your
repetitive timer loop.
When I did the OSX port, didn't know the 'solidness' of old ported
Microseconds() type functions, and didn't know what would be changing on
different OSX versions. So wrote a simple 'what time is it' function that
converts UpTime() to a double var in microseconds. On each entry to the Timer
callback, I get the current Microseconds, convert to MIDI TickTime (at the
current tempo), and send out any MIDI events that fit the time threshold, and
time-stamp and store any incoming events.
Sorry if that approach is so obvious it doesn't bear mention. Anyway, from my
experience if the Timer callbacks might have a jitter, even an occasional jitter
up to a few milliseconds, as long as you send out 'whatever is due to go out'
according to the REAL current time (rather than counting Timer Tasks), it can
sound pretty smooth to the ear.
So you could probably move your TimerTask code to a '1 mS sleeping thread' or
whatever and not suffer real bad timing even if the sleeping thread has some
wakeup jitter, as long as your playback code polls a lower-level steady timebase
every time it wakes up.
In my OSX Timer Task, I use a 'lock' var as you describe. In my case its a bool
'CurrentlyInTimerTask'. Nowadays its mainly to avoid re-entrantly entering the
Timer Task (if such is even possible on OSX). Am pretty sure it was possible
back on OS9, if you spent excessive time in a Timer Task. As you said, such
homebrew software vars are similar to various flavors of mutex.
There are programming strategies to minimize one's reliance on locks/mutexes. In
a MIDI program, it seems that there are rare cases not easily worked-around
where you have to manage access to certain variables to avoid corruption (with
mutexes or homebrew equivalents), but with the right strategies you can make
such situations rare.
You could google terms like "lock free queue". You basically make yer own
home-brew rules that Thread A is the only one that can write Variables A, B, C,
but Thread B is the only one that can write Vars D, E, F. But any thread can
read the vars.
JCJR
_______________________________________________
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