Here comes my first silly question of 2017! Happy New year to all, by the way, I hope that 2017 is fantastic and musical for all of you!
Right,
Page Faults. If I’m understanding right, the page faults happen when you’re using the swap file. I have no swap file on my machine, it has 32GB of RAM in it and I figured I didn’t need it. I’m running just Keyscape which according to the monitor is loading 3GB of samples to RAM. It’s not glitching in anyway, but when I play just one note, the pf indicator says around 6000-7000 page faults and when I play anything, it goes up to 10x that!
Now, as I said, it’s not glitching but I’m wondering if there’s something wrong with my setup that’s causing this?
It also happens when I’m using Kontakt (although smaller numbers, they’re around 6-7k when I’m playing) and also when I’m using things like FM8 which doesn’t use samples!
A Happy 2017 for you to.
It’s not a good idea to remove the pagefile, Windows needs an amount of pagefile in order to work properly.
So try to enable the pagefile and look if the pagefaults disappear.
From the e- book “GlitchFree” by Brad Robinson ( Cantabile Founder )
Diagnosing whether page faults are the cause of audio issues is particularly difficult:
• Page faults are a common and a normal part of the operating system’s functionality.
• Page faults on threads other than the audio thread generally don’t cause audio issues
in properly designed software but still show up in page fault metrics.
• Generally only hard page faults cause issues however most diagnostics tools combine
hard and soft page fault statistics making it difficult to tell what exactly is happening.
One of the best ways to monitor for hard page faults is with LatencyMon. The trick is to try
to correlate hard page faults with audio drop outs. One technique to try is this:
Make sure any screen savers and power save options are turned off.
Start your audio software and load up the session you want to test against. Make sure
any sample libraries are fully loaded.
Make sure your external MIDI keyboard is connected and routed to whatever plugins
you’re testing against.
Play a glissando across the full keyboard to help pre-load pages.
Start LatencyMon and press the green “Play” button.
Switch to the Processes tab, sort by name and locate the name of your audio program
and make sure it’s visible.
Step away from the computer – don’t touch the mouse or keyboard and just let it sit
there for a few minutes.
After a few minutes, play a chord of say 8 notes and watch the hard page fault count
in LatencyMon – if it jumps rapidly then you may have an issue with page faults.
Not a silly question at all - Windows memory management in general, and page fault specifically is really a bit of a black art.
Page faults are not only caused by accessing the swap file. They occur anytime a part of a memory mapped file is accessed that isn’t already loaded into memory.
When Windows opens a EXE or DLL (eg: a plugin) it maps the file to memory but doesn’t actually read most of the file. When a mapped memory address that hasn’t been loaded is accessed, the processor trips a page fault exception which Windows picks up on and it goes reads the disk to resolve the page fault after which the processor continues on as if nothing happened.
For example, the first time you bring up File Open dialog you’ll notice Cantabile’s page fault counter spike - that’s because even though the common dialog DLL is mapped into memory, the code that implements that dialog hasn’t yet been loaded - so it page faults and Windows fetches them as needed.
The same process is used for the swap file - when memory is tight and more room is needed, parts of memory will be paged out and the same page fault mechanism used to bring it back in when needed.
Besides these two cases (mapping executable code and the swap file) a Windows program can also explicitly map a file into memory and again the same page fault mechanism will be used to read the disk as necessary.
Here’s the problem though. There’s no easy way* to determine which thread the page faults are happening on. Page faults on the audio thread are bad because any disk I/O on the audio thread has the potential to introduce glitches. Page faults on any other thread are perfectly normal and no need for concern.
* I believe there are ways for a program to read per-thread page fault counters but I’ve not had the time to look into it in enough detail - it’d be great to be able to report an actually useful number here instead of just a hint that something might be amiss
Anyway… I’m not aware of the technical aspects of how Keyscape is implemented but perhaps they’re using memory mapped files. My guess (hope) is that they’re doing all this on a background worker thread leaving the audio thread running page fault free but giving a scary, but otherwise inconsequential page fault reading.
As I said, whatever the page faults are, they’re not causing any glitches, just was odd that Keyscape seems to have an order of magnitude higher amount…
