I'm trying to understand the mechanism by which the Quit Application menu item gets disabled while a modal dialog/alert is up. Who is responsible for disabling the menu item? We have a case where in some cases, the Quit Application menu item is not getting disabled even when a modal dialog is up. So I'm trying to figure out where things may be going wrong.

This happens even with SIP disabled. As soon as dtrace is terminated, the application continues execution. This happens with all apps. Nothing obvious in Console. How can I fix this?

Hi, Just discovered that taskinfo on BigSur no longer shows details of kernel task threads. Is there a way to get around this limitation? Thanks. Devendra.

Hi, I'm trying to use ShareArrayBuffer with Audio Worklets but it does not seem to work. It works fine with Chrome. The Share Array Buffer sample from here, works well with Chrome, but not with Safari. https://googlechromelabs.github.io/web-audio-samples/audio-worklet/design-pattern/shared-buffer/ There's no error indicated in the JS Console, either. This seems related to the following WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=237144 But that is marked as been resolved. Tried using the Safari Technology Preview (v 165) - but that has even bigger problems. It does not even recognize AudioWorkletNode class! Am I missing something? Thanks. Devendra.

We have encountered a problem where the dyld ends up using the incorrect dylib. Here's the use case: Plugin A (a bundle) depends on Dynamic Library A - referenced with "@loader_path". Plugin B (a bundle) depends on Dynamic Library B - referenced with "@loader_path". Relevant File (binaries) layout is like this: MyPluginA.bundle/Contents/MacOS/MyPluginA [depends on @loader_path/../../../MyLibraryA.framework/MyLibrary] MyLibraryA.framework/MyLibrary MyPluginB.bundle/Contents/MacOS/MyPluginB [depends on @loader_path/../../../MyLibraryB.framework/MyLibrary] MyLibraryB.framework/MyLibrary This scheme works fine on most machines. But on some Macs, dyld tries to link MyPluginB with the library in MyLibraryA - which causes the plugin not to be loaded because it cannot find the required symbols in the library. If we try to print dyld debug information, it shows that MyLibraryB is loaded and then unloaded, without showing any reason. And following that, the MyPluginB tries to look for MyLibraryB's symbols in MyLibraryA. Can this be due to some kind of caching done by dyld? Why is the @loader_path not being used to refer to the actual library being used?

We have noticed that in our application that creates worker threads for audio processing, these threads (time-constrained priority) in some cases do not run on the P-Cores (on Apple Silicon Macs). It was my understanding that once we use audio workgroups, the scheduler will always schedule our threads on the P-Cores. This works okay as long as the CoreAudio buffer size used is 256 samples or less (@ 48K). But if the buffer size is 512 or above, the threads are run on E-Cores (checked using System Trace). Is this expected behavior? Can I find any documentation for this (short of analyzing the scheduler source in kernel)? Thanks. Devendra.

Even when SIP is disabled. It shows an error, and dumps the dtrace script to console! Used to work fine until BigSur.

If I physically disconnect a MIDI (USB) device, the MIDI Studio correctly shows the device as offline, yet MIDISend does not return an error when trying to send to this disconnected device. I realize that MIDISend is deprecated for macOS 11.0 but we need this to work pre-11.0 Is this expected behaviour?