Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More Glitches

Jeff,

Thank you for your answer which is very helpful. However I still have some questions....

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.

This makes sense. But as I asked, why doesn't the OS implement some communications between the IO thread and the VM Pager, so that when a lot of VM page faulting occurs that the IO thread does not starve? Unless, of course, the page faulting is in the IO thread.

Shark will show you in excruciating detail when this happens, as will latency traces.

Can you please give me the settings or a configuration file for shark so that it exhibits this information?

The problem is that this happens more frequently when plug-in samplers are running. This makes it hard for the host to debug. These samplers may be doing heavy disk i/o at times to load samples or perhaps their sample buffers are not wired in memory and page faults occur.

It just does not make sense to me that we should get an audio glitch because a page in another thread/process is not loaded in memory! The OS should compensate for this.

Also note that when you debug an app with gdb, you are stopping all the threads in the app every time you hit a break point or otherwise cause gdb to halt the app. Consequently, you can expect to see many more overloads than usual.

On Feb 14, 2005, at 6:40 PM, Jeremy Sagan wrote:

Jeff,

I am not too familiar with the OS so I could be way off here but I also have some questions regarding glitches. I do get overload notifications though and they seem to happen way more if GDB is running.

Is it possible to get a glitch solely because of VM from a different thread? If another thread is taking a lot of page faults all in a row would that cause the I/O procedure to be starved? If the answer to the first two is yes, then shouldn't there be a mechanism in the OS that causes the audio I/O procedures to get called immediately after the first and between each page fault?

Jeremy

On Feb 14, 2005, at 6:46 PM, Jeff Moore wrote:

Glitches that don't correspond to over loads can be caused by lots of things. The usual cause is supply chain issues, but there have been a handful that are hardware/driver related.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

This email sent to email@hidden
References: 
 >More Glitches (From: Ethan Funk <email@hidden>)
 >Re: More Glitches (From: Jeff Moore <email@hidden>)
 >Re: More Glitches (From: Ethan Funk <email@hidden>)
 >Re: More Glitches (From: Jeff Moore <email@hidden>)
 >Re: More Glitches (From: Jeremy Sagan <email@hidden>)
 >Re: More Glitches (From: Jeff Moore <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.