Ioproc Scheduling Behavior
Ioproc Scheduling Behavior
- Subject: Ioproc Scheduling Behavior
- From: Chuck Carlson <email@hidden>
- Date: Tue, 16 Mar 2010 23:08:28 -0700
Hello,
We have an architecture that has the ioproc sending audio via udp to a dsp thread in another process on the same machine (might be on another machine in the future). The ioproc then waits in a socket function for the processed audio from the other process.
After startup, the system has mediocre performance as we increase the load on the dsp thread. That is, at about 60% load on one cpu of a C2 Duo, audio dropouts happen. But when we run Shark on the system, we can kick the system into great performance and can run 95%+ of one cpu. The jump in performance happens when Shark starts processing it's data after collection and remains after Shark is exited.
So, we've got some learning to do about thread scheduling so we can get this great performance without Shark.
So I'll ask some questions that may get us started, feel free to ask for more info.
I read on this list that HAL adjusts the real time constraints on the ioproc based on history of usage. So, does waiting in a socket affect this scheduling, as the thread may not be consuming the cpu cycles that HAL has allowed for it but is using most of the sample frame time?
Is there a way to know what the drop-dead time is for the ioproc? If we knew this, we could use a timed wait socket call. How would this affect ioproc scheduling?
When I call thread_get_state in the ioproc, I am seeing that it is set preemptable. The Mac OS X Internals book by Singh says that thread_get_state cannot be called on the current thread so this might not be valid info. Is the ioproc ever scheduled non preemptable?
The priority of the dsp thread is set using the mach real time constraints by the CAPthread class. The dsp thread also uses socket calls to wait for packets so it is sleeping in the kernel while it waits. Should the real-time constraints be reset at any point, like before or after a socket call? And again, Singh says that thread_set state can't be called on the current thread so this may need to be done elsewhere.
Any other good books, docs I should look at?
All for now, thanks.
--Chuck
_______________________________________________
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