Re: Audio threads scheduling
Re: Audio threads scheduling
- Subject: Re: Audio threads scheduling
- From: Jeff Moore <email@hidden>
- Date: Thu, 1 Apr 2004 15:43:52 -0800
You have a point about MillionMonkeys. It is a good example of the
priority inversion I was talking about in my other messages and why the
HAL does things a little differently with it's IO threads.
I wouldn't stress to hard over it. MillionMonkeys was originally
written to help stress out the system, all the while trying to simulate
the different strategies a real world audio engine might use for it's
threading. One of the lessons we learned from it is that having your
feeder threads be real-time isn't normally a good thing.
On Apr 1, 2004, at 3:20 PM, Stiphane LETZ wrote:
On 1 avr. 04, at 22:33, email@hidden wrote:
Message: 7
From: Jeff Moore <email@hidden>
Subject: Re: Audio threads scheduling
Date: Thu, 1 Apr 2004 11:39:04 -0800
To: CoreAudio API <email@hidden>
Sorry. I can't point to a specific file or something like that for you
to look at. I get most of my knowledge either by talking to the kernel
guys about it, from experimental evidence gleaned over the years of
working with the HAL's IO thread and from looking at the kernel traces
that get produced when things go astray.
If you really want to get down into the nitty gritty of how the
scheduler works at the code level, you should probably post your
questions to the Darwin-Dev mailing list. I think all the appropriate
folks who should be able to answer your questions monitor that list.
Thanks.
On the other hand, if you are trying to do something specific, you
should probably describe it and we can probably give you some good
advice as to how best to accomplish it.
Well I was mainly trying to understand the MillionMonkeys CoreAudio
SDK example.
With what you said about the "computation" parameter choice, I think
that there is now something unlogical inside the MillionMonkeys
example.
Indeed when the "feeder" thread in time-constraint mode is used, it's
period and constraints are correctly set with the buffer size value,
but the "computation" parameter is setup to 0.15* buffer_size
duration (in pThreadUtilities.c setThreadToPriority function)
Thus with large buffers (512) , the "computation" unpreempatable
time slice would possibly be too long to allow a thread with a small
buffer size to meet it's deadline.
Stephane Letz
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.