Re: overloads in ioproc : why?
Re: overloads in ioproc : why?
- Subject: Re: overloads in ioproc : why?
- From: Herbie Robinson <email@hidden>
- Date: Sat, 14 Sep 2002 20:59:40 -0400
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.