I am seeking advise on a subject I’m not versed in. To explain. I have been combing my performance system to track down potential causes for intermittent pops and glitches. I posted last week about MS Edge causing background task problems by using to much CPU at in-determinant times. Today I had a very slight episode of glitching and discovered that the memory manager for Windows 10 was drawing almost 100% CPU when it was compressing or decompressing memory. The reading I did on this said it could be disabled but before I did any experiments I was wondering if anyone knew more about this. It is supposed to help overall performance but the side effect is that occasionally it gobbles a lot of CPU to do it’s thing. It didn’t exist till Windows 10 FWIW. Curious if @brad has heard of this subject.
I’ve not done a deep dive on this, but my first reaction is to turn it off. Here’s my rationale:
I believe the idea is to compress memory before paging it to disk. Since the disk is the slowest part of paging by reducing the amount of data to be read/written the throughput should be higher.
However, the compression requires CPU processing to complete - which can take away from audio processing.
Also, I suspect the memory manager probably groups multiple pages and compresses/writes them all together rather than a single page at a time. That’s not based on any inside knowledge but just something it seems like it might do. If so, that means it could suddenly have a big chunk of work to do all at once. Again, bad for audio processing where it’s better for background tasks to be spread out over time.
So the compression might make overall throughput better, but the processing load for that becomes spikey rather than spread out.
By turning it off, it’ll take longer to read/write pages to disk, but while it’s happening the CPU can be busy doing other things - like audio processing.
The only case I can think of where this might help for realtime audio is if a plugin or something else on the audio thread page faults. In that case the page fault might be serviced more quickly, but I doubt it would make a big enough difference to prevent a glitch. Basically, if anything on the audio thread is page faulting then it’s probably going to glitch no matter what.
Just to be clear, if you’re seeing page faults reported in Cantabile that’s expected and not necessarily an issue. Cantabile can’t tell if the audio threads are page faulting, or other UI/low priority threads. It’s when you see page fault spikes accompanied by audio glitches you should be concerned.
Or… it could be that everything above is wrong - just my gut feel from how I understand it works.
Not directly to your question and I assume that you have done the Glitch free stuff.
Two things that are not mentioned often:
Go to msconfig services tab, click hide microsoft services and uncheck everything else. This is probably where your Edge got started. In my experience, anything that is really needed will start up later anyway.
The other is to try going to Cantabile Tools, Options, Audio Engine and changing Thread Affinity Mode from Cantable managed threads to System managed. I find that this often spreads the load better among cores.
Thanks for the tips. I’m in the process of optimizing a new backup PC and changing the thread affinity mode as John suggested made a significant difference. Haven’t tried the memory compression yet. BTW I’m getting an odd behavior on multiprocessor mode, if I’m getting a few glitches in compatible mode, I change it to aggressive and it’s better until I change songs. If I reboot cantabile then I’m getting a few glitches again, and change it to compatible, and it’s better until I change songs. Its as if simply making a change temporarily helps performance. Odd.
Tom
All this option does is tries to keep each audio thread on the same CPU core. Whether that helps can depend on the machine, the plugins and lots of other things.
