overloads in ioproc : why?
overloads in ioproc : why?
- Subject: overloads in ioproc : why?
- From: Benjamin Golinvaux <email@hidden>
- Date: Fri, 13 Sep 2002 11:30:16 +0200
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 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...)
Thanks for any suggestion and sorry for lengthy post..... I've now
reached the kWillTryEverything debugging level.
Benjamin Golinvaux
_______________________________________________
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.