Re: overloads in ioproc : why?
Re: overloads in ioproc : why?
- Subject: Re: overloads in ioproc : why?
- From: Benjamin Golinvaux <email@hidden>
- Date: Mon, 16 Sep 2002 14:31:58 +0200
Herbie,
I'm using the MP queues, but I'm wondering whether the MPNotifyQueue
call is a blocking call or not (i know it's possible to design lock
free queues, but since i haven't reserved any space for my queue, maybe
the memory allocation code that's executed from this call uses a global
std lib mutex to access the heap. I need to check this). And if this
call is blocking, does it use a "real time schedule" wait as you say
seems not to always be the case ? I think the docs should be more
detailed when it comes to these potentially complex issues.
Thanks for the advice regarding mlock. This is what I am going to
do......
Benjamin
ps : your "services for senders of unsolicted commercial e-mail" was my
best laugh of the day ! Does _this_ work ? Nice idea anyway ;-)
On Sunday, September 15, 2002, at 02:59 AM, Herbie Robinson wrote:
Dear list members
Since I installed 10.2, it seems the system is somewhat less tolerant
when the HAL ioproc is overloaded. For example, stopping the debugger
then resuming can cause the audio to stop for a few seconds. I've
read the "underflow causing permanent silence" thread, i know there
is a fix in the works but, if i understand correctly, problems
shouldn't happen if the ioproc does not overload for a long time,
right ? (okay i'd love coreaudio to instantly recover from a debug
session as it seems it did in 10.1 but i don't really need this now)
Under some conditions (really unclear at this point) some testers of
our application report experiencing this very problem :
hiccups/silence in the audio output for a few seconds. They're not
debugging it of course. And I've seen it on my system a couple of
times, too (this happens with several drivers : built-in for several
different Macs, delta 1010, roland UA30, ...)
Now the weird thing is : Mr Tim Wood reports that this problem only
happens if he stops in the debugger for too long a time. If it
happens in my release code, it means the ioproc sometimes gets
blocked for more than 1sec ?! But then, if it is so, why was it
running ok under 10.1 ? I'm puzzled......
I've tried to examine the many ways my ioproc could block, but i
don't really find a lot of these. I'm using MPNotifyQueue from the
ioproc, but the thread that retrieves messages from the queue has a
high priority too (fixed priority 63) so it shouldn't block for a
long time (hope i'm not making a wrong assumption here). OK this
might cause occasionnal drop-outs maybe (i need to switch to a
lock-free scheme in the future) but I was expecting this not to cause
this kind of looooong sync losses as seen when resuming from the
debugger. (i double-checked i wasn't using any system call in my
ioproc except for memcpy and memset). Also please note it also
happened with very modest system loads, and virtually empty dsp
processing.
A potential problem I see : the ioproc sometimes reads from- and
writes to buffers allocated with malloc (the actual malloc call is in
another thread) and I wonder if i need to "touch" them once before
handing them to the ioproc. The problem is : these buffers are not
accessed all the time : they can get unaccessed for an indefinite
amount of time. Would it be possible that page faults could block the
iothread so long that it could cause a sync loss?
(it probably takes a big amount of simultaneous page faults required
to block a thread so long that the "underflow causing permanent
silence" happens!)
I've been experimenting with a real time transmit thread in my MIDI
testing application and have also been noticing timing curiosities. I
put in some instrumentation to keep track of how long my codes runs
before it sleeps. On average, it takes 100 microseconds to queue up
the next batch of time-stamped MIDI messages, but some times it has
taken as much as 11 milliseconds. I do allow preemption; so, I don't
know whether this is just an interrupt or if I'm taking a few page
faults. A page fault is likely to take a msec or two; so, that is
possible. 11msec is an awfully long interrupt... It does
occasionally fail to deliver on the real-time constraints.
I do have one theory: I have discovered that the kind of wait you do
affects whether or not you get real time behavior (for example,
sleeping with nanosleep gets real-time scheduled, but sleeping with
the time-out on select does not). It's possible that page faulting
uses a wait that doesn't get you into the real-time scheduler when the
page becomes available.
Actually, it isn't at all clear what the real-time guarantee is when
you allow preemption. Is the system only guaranteeing that the task
starts at least the specified time before the end of the interval, or
is it guaranteeing that the task will be able to finish executing
before the end of the interval (where preemption is not allowed, this
is the same thing, but the guarantees become different when preemption
is allowed).
I've seen lots of discussion on this list wrt wired memory. Is there
now a public and apple-recommended way of locking a modest amount of
physical ram for audio dsp stuff ? I've seen some calls need to user
to be "root". Does this mean any 'sudoer' user (including the default
user created at osx installation time) could do this ? (yes that
would be nasty to require this but...)
I reported a bug in mlock (a POSIX call) and they fixed it. If they
didn't intend for it to be used, they wouldn't have fixed it.
So we definitely have mlock and munlock. You can use these with an
allocation wrapper to have a wired heap. It might be cool to unwire
everything when you application is idle, too.
There is also something called task_wire. The comments claim it sets
a switch that causes everything subsequently allocated by the task to
be wired. I believe this use for this would be to set the switch
before loading plug-ins and starting new threads to ensure that memory
allocated for the new objects gets wired.
You don't have to be super-user to use either of these. I managed to
follow the code for mlock far enough to ascertain that it checks
against limits to keep devious processes from crashing the system.
Task_wire was too hard to follow, but presumably it has the same
checks.
Benjamin Golinvaux
--
-*****************************************
** http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.