Re: How should I do the sequencer thread on OS X?
Re: How should I do the sequencer thread on OS X?
- Subject: Re: How should I do the sequencer thread on OS X?
- From: Robert Grant <email@hidden>
- Date: Fri, 4 Jul 2003 08:32:00 -0400
Hi Yasir,
I talked to Jeff Moore about this kind of thing at the conference (he's
probably on holiday today :-)) and he recommended using a HAL IO Proc
as a timing source. Apparently the IO Proc is running in a realtime
thread that has very consistent execution properties. The new
MusicPlayer in the AudioToolbox uses this approach.
I don't think it guarantees to be as tight as an interrupt - but you
certainly won't get kicked out for 500 ms!
Hope that helps,
Robert.
On Friday, July 4, 2003, at 04:15 AM, Yasir Assam wrote:
Summary: Should I use InsTime/PrimeTime or do I need to use pthreads?
Or
something else?
I'm having problems with my sequencing code on OS X. My code uses
Carbon and
runs on Classic as well as OS X. It uses InsTime() and PrimeTime() to
get a
regular callback (every millisecond). This callback code then checks
to see
if there's any events ready to be executed (such as MIDI events) and
deals
with any ready events.
The code runs fine on Classic but on OS X the sequencer is stalling
momentarily now and again (e.g. for about 500ms).
I know that on Classic the callback from PrimeTime() gets called by
interrupt code in the OS and runs to completion. I also realize that
the
same code on OS X runs within a regular thread that can be preempted,
and
that's fine.
What I'm finding (and I'm 90% sure about this) is that when the timer
callback is called on OS X, it can sometimes be pre-empted for very
long
periods (up to 1 second) before it gets execution back. In other words,
somewhere in the middle of executing the callback, OS X pre-empts that
thread and doesn't give execution back for hundreds of milliseconds.
This
doesn't happen that often but it happens often enough to make the
sequencer
stutter now and again.
Of course it's possible that the callback function itself is taking a
very
long time to do its thing and pre-emption is not the problem, although
this
is unlikely. The callback function itself shouldn't take more than 5
milliseconds to execute (and should usually be much quicker than that).
I should add that the main app thread is doing quite a lot during
playback
(lots of window redraws using OpenGL) and my system is quite slow.
However,
I'd still like to have a thread that is guaranteed regular attention.
It
shouldn't be interrupted for more than a few milliseconds, no matter
what
happens, but this shouldn't be at the expense of system stability of
course.
I assumed that a PrimeTime callback would run in a very high priority
thread.
I should also add that the callback thread and main app thread call
Enqueue
and Dequeue to communicate with each other.
Should I be creating a thread with an even higher priority than the
one that
is used for timer callbacks? What's the recommended way of doing this
on OS
X?
Thanks,
Yasir Assam
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.