Re: More thread scheduling observations
Re: More thread scheduling observations
- Subject: Re: More thread scheduling observations
- From: Bill Stewart <email@hidden>
- Date: Sun, 05 May 2002 14:17:48 -0700
on 4/5/02 3:49 AM, Kurt Revis wrote:
>
I spent some time yesterday playing around with my code which implements
>
a feeder thread (reading audio from a file) which communicates with my
>
IOProc via a ring buffer. I have some interesting observations --
>
anyone have any experience with this sort of thing, or comments?
First and most importantly:
(1) What is the policy that you set on the feeder thread
(2) What is its priority
>
* The easiest way to cause dropouts is to drag a fairly large window,
>
continuously, for a large period of time. Even if nothing else is
>
happening on the machine, it seems that the window server process gets
>
priority and starves out my feeder thread.
This is a known problem in a 10.1 system and we believe this has been
addressed (through numerous changes) in Jaguar.
>
A good way to see this is with the 'latency' tool (/usr/bin/latency). I
>
just ran it and dragged a window around, continously, for a while. Sure
>
enough, the maximum latency(usecs) went up to 13237437 ... that's 13
>
seconds!
There will also be a new tool in Jaguar that we've written called "Million
Monkees" (Look for it in the CoreAudio examples directory). It is set up to
emulate a feeder thread to an IOProc, and uses latency to do traces - but
the traces are localized to the feeder thread's wakeup. We are really hoping
that developers can run this tool and report any problems they see with this
tool (including the trace of course).
>
So it appears that the worst-case wakeup time for an ordinary thread is
>
essentially unbounded. The best one can do in this situation is to have
>
a really big buffer between the feeder thread and the IOProc, and assume
>
that one's users won't be terribly cruel.
>
>
* Other kinds of load are not nearly so bad for scheduling. I can do an
>
'ls -lR /' in a terminal window and have iTunes running a big
>
visualizer, and the machine definitely gets less responsive, but my
>
feeder thread still wakes up pretty close to when I want. All this other
>
work is happening in processes with ordinary priority, as far as I know,
>
which explains why they are not causing problems. It's the high-priority
>
window server process that is causing the problems seen above.
>
>
* iTunes is really good. I have great difficulty getting it to drop out,
>
even when I torture the window server. (I have heard dropouts at other
>
times, like when I scroll the view in Mail that I'm typing in right now.
>
But I can't get it to happen intentionally.)
It buffers substantially far ahead to achieve this
>
How does iTunes do it? I am guessing that it has a big buffer -- vmmap
>
shows that it has a big chunk of memory allocated (8704K), but I haven't
>
verified that that's actually an audio buffer. (And maybe it's just used
>
for those 12-second crossfades.) I haven't delved in to check its
>
threads' scheduling policies, either.
>
>
* The QuickTime player, on the other hand, is pretty poor. It is
>
surprisingly easy to cause dropouts by dragging a window around while
>
it's playing. I don't feel so bad about my code after noticing this :)
>
>
* I was just using read() to get my samples from an AIFF file. Then I
>
started using QuickTime to read the samples, using the technique in this
>
example:
>
>
http://developer.apple.com/samplecode/Sample_Code/Sound/MP3Player.htm
>
>
This uses GetMediaSample() in QT to read samples from a file, and then
>
the SoundConverter (QT/Sound Manager) to do decompression and format
>
conversion.
>
>
Unfortunately, doing this seems to make my program much more susceptible
>
to dropouts. I'm not sure why this would be happening, though. (And I'm
>
not sure how to measure the effect exactly.) The only thing I can think
>
of is that the QT calls are somehow causing my feeder thread to block
>
more often. Anybody have any ideas?
>
>
* While investigating the above, I noticed that the Sound Manager
>
installs its own IOProc, even though I'm not using it to play any sound.
>
(This seems to get set up when I first create a QT movie.) This is
>
probably not a big deal (although I wish it weren't there taking up
>
processor time). However, I noticed that this IOProc is calling
>
pthread_mutex_lock() every time through! Isn't that exactly what we've
>
been told not to do?
This sounds to me like a bug, or at the least something we should
investigate
>
>
I thought perhaps my problems with QT were related to this, because
>
GetMediaSample() and the SoundConverter also lock some mutexes. However,
>
it doesn't seem that they are trying to lock the same mutex as the
>
IOProc, so this is probably not the problem.
>
>
* If I set my feeder thread to use the time-contraint policy, it works
>
fantastically well. Even with a tiny (64k) ring buffer, I can't get it
>
to drop out. So I'd really like to know why this approach is not
>
recommended. (Maybe if I were reading a file over the network, or some
>
other slow medium, things would not be so wonderful?)
It places you're feeder thread into a very high priority band that will:
(1) Compete directly with the I/O and potentially cause you to miss an I/O
cycle
(2) Above many of the activities of the OS in general.
>
* Instead of that policy, I tried setting my thread's precedence
>
(THREAD_PRECEDENCE_POLICY) to a high value. This is not as fantastically
>
reliable as the time-constraint policy, but it does seem to help a great
>
deal. Even with a small buffer (256k) it is pretty hard to get
>
dropouts... about as hard as when I used a 4 MB buffer with an ordinary
>
thread. This seems like the best tradeoff to use, so far.
>
>
Apple guys: I know Bill Stewart said that you'd be discussing this at
>
WWDC this year. Unfortunately we can't all be there--can I ask that you
>
summarize the issues somewhere public, like on this list or in a
>
technote or something? Thanks!
We'll see if we can get this out in some form after the conference - a
summary of the salient points...
There are other changes that have been made in the OS that effect this, so
if anyone is going to be at the conference there are probably a few sessions
that will be worth attending that have a baring on these issues.
Bill
>
--
>
Kurt Revis
>
email@hidden
>
_______________________________________________
>
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.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
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.