Quasi-realtime threads
Quasi-realtime threads
- Subject: Quasi-realtime threads
- From: Ethan Funk <email@hidden>
- Date: Thu, 25 Jun 2009 13:34:34 -0700
I have established a ring buffer that gets filled by an output devices
render callback with in my application. The callback also triggers a
pthread semaphore, which at some point in the systems scheduler future
wakes a "push" thread to read the new data from the ring buffer,
process it, and send it out a network socket. The problem is, the
timing on the push thread is very jittery, and when I add AU
processing to it, performance is not acceptable, as all the AU
processing takes place on the push thread, which is not a time-
constrained thread. So, I tried using a deferred render AU between
the push thread and the ring buffer reading to force at least the AU
rendering to be realtime. Performance is still poor due, I think, to
the deferred render being pulled on by a jittery thread. I assume the
deferred render AU wants to be pulled on by a realtime thread too.
Since I can not create a time-constrained thread for the pull process,
due to the potential for blocking (network socket), it there some sort
of threading policy which will allow my pull thread to almost be a
time-constrained thread? Something where I request a certain number
of time slices in a given period, but give them back (yield) if I
can't use them due to a blocking condition?
Ethan...
_______________________________________________
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