Comment by astrange
5 months ago
This is not fixable. You’d need an RTOS.
(You can’t mlock every single code page possibly executed by the thread for instance.)
5 months ago
This is not fixable. You’d need an RTOS.
(You can’t mlock every single code page possibly executed by the thread for instance.)
Why wouldn't it be possible to mlock all the memory pages used by the real-time thread?
I do my best to do it on the application side. It would be nice if Apple's CoreAudio did the same.
If you mean that it is difficult to identify the pages used, that is true, but I found a great way to do just that. I keep track of all the pages I mlock(), list all the remaining pages, and mprotect them to crash if I accidentally access memory that was not mlocked. That helped me identify a couple of pages I forgot, such as the one that contains the __stack_chk_guard
And regarding the code pages, for some reason I get a permission denied error if I try to mlock them. Not sure why.
There is no mlockall() on macOS, but if there was one, I could delegate the real-time audio handling code to a separate executable, and call mlockall(). I would be guaranteed all the pages used by the real-time thread would be mlocked.
And by the way if you are interested in the report I sent to Apple, you can find all the details with the sample code to reproduce the problem there:
https://twistedwave.com/AudioGlitches.zip
How much memory could a single system thread handling the audio use? Forgive my ignorance I don't deeply understand OS level memory management but I thought, much like the task scheduler has priority understanding for CPU resource management, the memory manager had an idea of "these pages are important find some other page to evict".
> How much memory could a single system thread handling the audio use?
It's not "use" but "ever potentially access", so it's unbounded unless they were careful. (Audio playback to speakers itself is bounded, but mixing isn't, and wireless headphones get complicated.)
> Forgive my ignorance I don't deeply understand OS level memory management but I thought, much like the task scheduler has priority understanding for CPU resource management, the memory manager had an idea of "these pages are important find some other page to evict".
It's difficult to know what the most important pages in memory are, because you'd have to observe every single memory access, and that's not worth the overhead.
Basically there's two ways it uses:
1. a program can tell the OS to keep something in memory (either by hinting it or forcing it, called mlock or wiring).
2. every so often, the OS will disconnect some pages such that accessing them faults (called "moving to the inactive queue"). If there's a fault, it know it's being used and moves it to active again. Eventually, if there aren't any for long enough, it gets to the end of the inactive queue and is paged out.
About 25 megabytes for an approximately 10-second buffer.
I believe 96KHz/24bit is the highest quality audio supported natively on the MacBook Pro.
24 bits * 96KHz * 2 channels * 4x safety factor = 2.3 Megabytes per second.