Any news on that issue?

--timestamp=none is generally not a good ID as your signature gets invalid when its signing certificate validity expires! You will not recognize any issue with the signed binary until the end of the validity of the certificate.

Thanks, for giving me the chance to soliloquy. The issue persists in Bug Sur, we have worked around this by requesting a USBDeviceReEnumerate(); This continues to work on M1 for some USB devices, while for others the interface iterator is still empty and is not getting filled by any magic we tried. In this case the USB device is pretty simple it has a single configuration with 2 interfaces. What is the cause for this and can this be fixed/worked around?

Thanks, Quinn! For debugging purpose and exchanging of logs/dumps its sometimes easier to directly write to log files. Which are suitable locations to write from CoreAudio and CoreMIDI? (We see that permissions do change between the MacOS versions.) Thanks, hagen.

Thanks for giving the space to get lost in soliloquies! After this breathing practice, I would now like to get back to work and finish the exercise, for example with the help of an appropriate documentation or a hint from the people behind the API/technology. Or you could also just tell me that your operating system does not need my support, then I could go straight to the beach and wouldn't need to wait for the bus here.

Thanks @endecotp! But isn't syncstream not part of the standard, and therefor shouldn't it be available to Xcode?

Enlightening! So, where is the documentation?

Thank you very much, Quinn, We need to set the thread priority for our streaming engine. Our unit tests are testing its modules - beneath other things - with all kinds of (unrealistic) sample rates. And it tries to set thread priorities for standard sample rates like 44.1kHz, 48kHz, ..., 192kHz, etc. while setting up the streaming engine to run on block sizes from 1 sample to something like 16384, which means the thread needs to be set up for computation down to every 1/44100, 1/192000 sec, etc. IIRC setting the thread_policy below 4/44100 fails. Although this is (for our current tasks) not a very realistic scenario, I think it should work, at least I would like to know how low the unit tests can go, or even better be able to ask the specific machine about its valid thread_policy range.

Thanks Quinn, for your reply! Subpackages are only notarized within our overall product. They are not notarized independently. Because reading your text I get the impression that it’s the latter, but the notary log snippet you posted doesn’t show any nesting. isn't this the indication: "message": "b\"Invalid component package: mypackage_vstpreset Distribution file's value: #com.mycompany.mypackage.vstpreset.pkg\\n\"", its the com.mycompany.mypackage.vstpreset.pkg that contains the non-binary preset files. Thanks

Thanks Quinn, yes, the example works, as well as our countless other installer projects. Also the previous .pkg submission prior to the latest content update succeeds. The updated installer .pkg itself can be installed without any issues in the installer .log.

I found the issue: a line choice was missing for a given choice element. Now the thing is that productbuild does not complain as well as it never returns an error value once the distribution.xml has passed checks for formal xml correctness. The notarization issue is cryptic enough to let me spend days on investigation. And it's certainly not my first .pkg installer... Thanks anyways!

issue has been found, has nothing to do with CFArray. Sorry to bother...

My mistake. It's working as expected. Sorry for the noise!

Dear Quinn, thank you very much for your - as always - very detailed and helpful answer! Just a note, we use the CoreAudio preferences to store CoreAudio server plugin preferences. What the plugin tries to achieve is to share some settings across various components. I see now that the SCPreferences are not the right option to do this. Using the CoreAudio preferences from other components probably is not a good idea either because this would imply knowledge about the storage for these components. Probably the correct way to do this is via CoreAudio custom properties. Thanks, Hagen

Thank Kevin, Ouch. I suspect what's happening is that you're presenting the devices you create in a way that makes each of them appear "unique" which is probably worth avoiding/thinking about (see #2 below). However, that's 1Mb is also getting a bit absurd (a plist file is not a database), so please file a bug and post the bug number back here. Make sure you attach the plist files to the bug so the team can see what's actually going on. Yes, they currently appear with a different UID each time. This needs to be fixed on our side. But I am not sure if the file size is an Apple bug. Isn't it more an unexpected use of this system? Anyway, as suggested I filed the bug report FB17384333. I'd just delete the entire file the reboot*. You'll obviously lose data, but the system should recover automatically. If it doesn't then it's our bug** that we should fix. I would love to lose these data though; unfortunately everything recovers! sudo rm /Library/Preferences/Audio/com.apple.audio.DeviceSettings.plist sudo rm /Library/Preferences/Audio/com.apple.audio.SystemSettings.plist sudo reboot ...and magically everything appears untouched. Thanks for all your help and suggestions!