Re: Interrupted audio
Re: Interrupted audio
- Subject: Re: Interrupted audio
- From: Jeff Moore <email@hidden>
- Date: Mon, 1 May 2006 18:00:53 -0700
On May 1, 2006, at 5:28 PM, Jeremy Sagan wrote:
Hello Jeff,
Please just answer this question. Is it possible to have a
perfectly well behaved and properly written program glitch simply
because of the Finder or some other application (or plug-in)
accessing memory?
I have yet to see a glitch caused by some other process accessing
memory, and I have debugged any number of glitching problems. Not a
single one was _ever_ tracked back to a memory access in another
process.
If you have such a case, please document it and file a bug. We are
definitely interested in poking at it.
I quote you...
On Feb 15, 2005, at 2:36 PM, Jeff Moore wrote:
The VM Pager is one of the few threads that are actually higher
priority than a time constraint thread like what the HAL uses for
IO threads. So, if you have another thread that is page faulting,
it can and will interfere with the performance of the IO thread,
usually by pre-empting it or causing extra latency when
scheduling it.
When you say "if you have another thread" I think you mean "Another
system wide thread" since any thread can cause a page fault. Right?
Yes any thread, including the IO thread, can cause a page fault. In
fact, one common glitch I see in many apps is a page fault in the
first IO cycle caused by the paging in of the app code touched by the
IOProc.
That said, my experience has been that VM Paging is not one of the
high order causes of glitching in applications on OS X. In fact, such
glitches have seemed to be a lot more rare than I would have expected
when I started on the HAL many moons ago. When a glitch due to VM
paging has happened, it has usually been due to cold code or cold
data in the application itself. I would classify such problems as app-
caused, as it is trivial to warm the code paths and data paths in
your app prior to starting IO.
Note, that a glitch due to VM paging not directly attributable to app
behavior (like cold code on the IO thread) would definitely qualify
as a bug that we'd like to look at, provided it can be properly
documented.
Finally, not to point out the obvious but the work around for VM
issues is to buy more memory. It's cheap and the benefits of more
memory to the system go way beyond causing fewer VM page faults.
(Aside: Actually for many kinds of common page faults, more physical
memory will do absolutely nothing for preventing them. The reason why
is that the system tends to be as lazy as possible when it comes to
paging in freshly allocated pages of memory. For example, when code
is loaded, it doesn't get paged in until the processor needs it for
the first time. No matter how much physical memory you have, this
kind of page fault will still occur.)
Jeremy
On May 1, 2006, at 6:14 PM, Jeff Moore wrote:
One other thing, saying that OS 9 performed like you seem to think
it did, is also not quite right. OS 9 never ever performed in that
way. Glitching was just as likely there as it is on OS 9. In fact,
it was way worse judging from the bugs I had to fix there over the
years. I think you are looking at the past through some rose
colored shades =)
On May 1, 2006, at 3:07 PM, Jeff Moore wrote:
If you see a bug, you should file it so we can fix it. Otherwise,
my experience has been that nearly all overloads in applications
are caused by the actual app doing something stupid, like
blocking in the IO thread on that lock that they swear is never
going to be contended for or making an API call and not
accounting for side effects (like blocking).
I can't begin to count the number of developers who have said
what you are saying only to find that when they put a real
magnifying glass on their problem, it turns out to be completely
their own making. That's not to say that there aren't bugs in the
OS. I'm positive that there are, but saying things like this is
not at all helpful in tracking these bugs down be they in the OS
or the applications. Just wishing all the apps out there didn't
have bugs that cause glitching isn't any more helpful that
wishing the OS would wave it's magic wand and make all the
problems go away.
So please, if you are seeing a problem and think it is in the OS,
document it, report it and we'll fix it. It's really that simple.
Given the state of the tools today, it's not even that hard to
document anymore. Between HALLab and Shark, folks should be able
to zero in on bugs like this pretty quickly.
On May 1, 2006, at 2:51 PM, Jeremy Sagan wrote:
I know I have written about this before and I love OS X in most
respects but it just seems like a step backwards from OS 9 with
the pervasive Core Audio overloads that could be caused by the
finder or any other process allocating memory. I am hoping and
wishing that Apple can address this system level issue in a
future OS update so we can go back to the days when we were
guaranteed that audio would play smoothly and without
interruption under normal operating conditions.
Jeremy
On May 1, 2006, at 5:07 PM, Kevin Avila wrote:
There is now a Technical Q&A online that explains overloads
that may be of help. http://developer.apple.com/qa/qa2006/
qa1467.html
Kevin Avila
DTS Audio Engineer
World Wide Developer Relations
Apple Computer, Inc.
On May 1, 2006, at 2:02 PM, Jeff Moore wrote:
My guess would be that the app in question is experiencing
overloads. It would be easy enough to check using HALLab's
telemetry viewer.
On May 1, 2006, at 1:54 PM, david tay wrote:
I have an USB audio device that on occasion has 0s (zeros)
inserted into the output audio stream at higher sampling
rates (eg - 96khz), causing the audio to become interrupted.
What would be the likely causes?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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