← Back to context

Comment by TwistedWave

5 months ago

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