Hi,
we have multiple threads in our CoreAudio server plugin carrying out necessary asynchronous work (namely handling USB callbacks and shuffling the required data to the IO).
Although these threads have been set up with the appropriate THREAD_TIME_CONSTRAINT_POLICY (which actually improves it) - on M* processors there is an extremely high, non-realtime amount of jitter of >10ms(!)
Now either the runloop notification from the USB stack comes that late or the thread driving the runloop hasn't been set up to correctly handling the callbacks in a timely manner.
Since AudioUnits threads requiring to comply to the frame deadlines can join the workgroup of the audio device is there a similar opportunity for the CoreAudio server plugin threads? And if so, how should these correctly be set up?
Thanks for any hints! Or pointing me to the docs :)
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi,
we have .pkg install package consisting of various sub packages. One of them contains presets and needs to be installed the the default preset location /Library/Audio/Presets. If this non-binary preset package is the only one in a .pkg choice notarization fails with:
"logFormatVersion": 1,
"jobId": "*",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "mypackage.pkg.zip",
"uploadDate": "2024-08-22T21:24:03.251Z",
"sha256": "*",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "mypackage.pkg.zip",
"message": "Package mypackage.pkg.zip has no signed executables or bundles. No tickets can be generated.",
"docUrl": null,
"architecture": null
},
{
"severity": "warning",
"code": null,
"path": "mypackage.pkg.zip/mypackage.pkg",
"message": "b\"Invalid component package: mypackage_vstpreset Distribution file's value: #com.mycompany.mypackage.vstpreset.pkg\\n\"",
"docUrl": null,
"architecture": null
}
]
}
Not sure, but maybe its worth noting that the causing sub packge only generates a warning, but the parent package seems to escalate this into an error.
How can a non-binary sub package be included in a notarized parent package?
Any hints or thoughts are highly appreciated, Thanks!
I have various main Xcode projects referencing the same Xcode sub projects. However Xcode only allows to open one of the main projects with the shared sub project available for accessing its files and building.
How can I create main projects that are able to open shared sub project at the same time?
Topic:
Developer Tools & Services
SubTopic:
Xcode
Hi,
our CoreAudio server plugin supports different clock sources. A switch might result in a change of the selectable sample rates (and other settings). On a clock source switch the plugin reconfigures the set of available kAudioStreamPropertyAvailablePhysicalFormats and announces the change via AudioServerPlugInHostInterface::PropertiesChanged(). However at least the Audio MIDI Setup seems to ignore to update it's UI. The changes are first reflected after selecting another device and re-selecting the device of interest. (Latest macOS, M4 macMini)
Is this a bug? Or is our CoreAudio server plugin required to indicate the change in the list of available audio formats differently?
Thanks!
Hi,
macOS (latest macOS, latest HW, but doesn't matter) seems to prevent CoreMIDI driver logging with standard logging procedures (syslog, unified logging).
The only chance to log something is writing to a file at one of the rare write-accessible locations for CoreMIDI.
How is this supposed to work? Any hint is highly appreciated. Thanks!
Hi,
when a CoreMIDI driver controls physical HW it is probably quite commune to have to control the amount of MIDI data received from the system.
What comes to mind is to just delay returning control of the MIDIDriverInterface::Send() callback to the calling process. While the application trying to send MIDI really stalls until the callback returns it seems only to be a side effect of a generally stalled CoreMIDI server. Between the callbacks the application can send as much MIDI data as it wants to CoreMIDI, it's buffering seems to be endless... However the HW might not be able to play out all the data.
It seems there is no way to indicate an overflow/full buffer situation back the application/CoreMIDI. How is this supposed to work?
Thanks, any hints or pointers are highly appreciated!
Hagen.