I'm developing custom AudioDriverKit and MIDI DriverKit drivers for a hardware audio-MIDI device on an M-series iPad. I've encountered a reproducible issue where advertising the audio device's correct USB transport type prevents iPadOS from making the device available to audio applications, whereas advertising Thunderbolt allows it to function. I've previously reported this issue through Feedback Assistant but have not received a response: FB25067968. Environment Hardware: BOSS SY-1000 connected to an M-series iPad via Apple USB-C Digital AV Multiport Adapter Audio: 48 kHz, eight inputs and eight outputs, interleaved Float32 DriverKit SDK: 27.0 Xcode: 27.1 Minimum iPadOS: 18.0 AudioDriverKit deployment target: 21.0 Separate AudioDriverKit and MIDI DriverKit extensions using USBDriverKit Proprietary USB isochronous audio transport The SY-1000 is a USB device, not a Thunderbolt device. The physical USB connection and hardware configuration remain unchanged between tests. Audio behavior Configuration A — Transport type: Thunderbolt When the audio device advertises IOUserAudioTransportType::Thunderbolt: The audio driver loads and registers. iPadOS makes the device available to audio applications. StartDevice/StartIO is invoked. Eight-channel audio input and output function. This has been our established working configuration. Configuration B — Transport type: USB Changing the two transport-type assignments to IOUserAudioTransportType::USB results in: Driver initialization succeeds. AddObject succeeds. RegisterService succeeds. HAL successfully establishes its user-client connection. HAL recognizes the 48 kHz, eight-channel Float32 formats. iPadOS audio-route creation fails. The audio device is unavailable to audio applications. StartDevice/StartIO is never invoked. No USB audio transfers occur. MIDI continues working The SY-1000's MIDI functionality remains available even when the audio device disappears. The project uses a separate MIDI DriverKit extension, attached to the SY-1000's MIDI USB interface. Under the failing USB audio-transport configuration: The SY-1000 remains physically connected and enumerated over USB. The separate MIDI driver continues to be detected. MIDI functionality remains available to MIDI-capable applications. Only the AudioDriverKit device fails to become available as an audio interface. This is an important distinction: the SY-1000 has not disappeared from the USB system. The problem appears specific to AudioDriverKit/Core Audio device routing

I'm developing an iPadOS USB audio-MIDI driver for a hardware device. The audio side uses AudioDriverKit and USBDriverKit (DriverKit SDK 27.0, AudioDriverKit deployment target 21.0, iPadOS 18.0 minimum). I need clarification about the ordering between IOUserAudioDriver::Stop, StopDevice/StopIO, and in-flight IOOperationHandler callbacks. According to Apple's DriverKit documentation, IOService::Stop must quiesce outstanding operations before invoking its superclass implementation. AudioDriverKit documents host-controlled audio I/O and the StopDevice → device StopIO sequence. However, I cannot find an explicit guarantee that the framework has stopped and drained all BeginRead/WriteEnd callbacks before invoking the driver's service Stop. Relevant implementation (simplified): // Audio driver service termination kern_return_t result = StopUSBTransport(); if (result != kIOReturnSuccess) { return result; } // Release resources and close provider interfaces. return Stop(in_provider, SUPERDISPATCH); The transport retirement path currently refuses to release resources while framework I/O is marked active: if (__atomic_load_n(&ivars->m_adk_running, __ATOMIC_ACQUIRE)) { // Retain ownership; resources cannot be released safely. return kIOReturnBusy; } The local running state is cleared following successful device superclass StopIO, but this does not independently establish that already-entered framework audio callbacks have returned. The USB teardown separately prevents new submissions, aborts outstanding transfers, waits for cancellation acknowledgements and native callback completion, and retains resources if ownership cannot be proven safe. An offline regression exercising service termination while framework I/O is marked active reproduces the Busy result. We have not established that AudioDriverKit delivers this ordering on physical hardware. Questions: Before invoking IOUserAudioDriver::Stop, does AudioDriverKit guarantee that StopDevice/StopIO has completed and that all outstanding IOOperationHandler invocations have returned? If not, what supported mechanism can a driver invoke during service Stop to prevent new BeginRead/WriteEnd callbacks and wait for already-entered callbacks to finish? Does calling superclass IOUserAudioDriver::Stop establish this callback-drain boundary? If so, how should hardware and USB resources be shut down when provider access is no longer permitted afterward? If termination cannot safely complete, is returning kIOReturnBusy a supported way to defer service termination? Is a subsequent retry guaranteed? I'm looking for the documented lifecycle and synchronization contract, rather than a workaround based on assumed callback ordering. Any clarification from Apple's DriverKit or Core Audio engineering team would be appreciated.

I am developing an independent macOS compatibility driver for the Avid/Digidesign Eleven Rack, an EOL USB audio device that does not have an Apple-silicon-compatible OEM driver. The existing hardware identifies as: Vendor ID: 0x0DBA — Digidesign/Avid Product ID: 0xB011 — Eleven Rack Transport: USB 2.0 high-speed isochronous audio The proposed implementation uses AudioDriverKit and USBDriverKit. It consists of a DriverKit system extension packaged inside a macOS control application. The USB entitlement would be restricted to this exact VID/PID. I am an independent developer and do not own the Digidesign/Avid VID. I am not manufacturing hardware or attempting to use that VID for a new USB product. The driver would only match existing Eleven Rack devices. The implementation is independently written for interoperability, and no Avid executable code would be included. I currently have a working direct user-space USB proof of concept, but I cannot properly activate and test the AudioDriverKit extension with SIP enabled without the required entitlements. Before enrolling in the paid Apple Developer Program, I would appreciate clarification on the following: Does Apple consider DriverKit development and distribution entitlement requests from independent developers supporting existing EOL hardware when the developer does not own the device’s VID? Is written authorization from the VID owner always required, or are these requests evaluated individually? Would restricting the USB transport entitlement to the exact 0x0DBA:0xB011 device affect eligibility? Is there a way to obtain an initial eligibility determination before purchasing Apple Developer Program membership? The anticipated entitlements are: com.apple.developer.driverkit com.apple.developer.driverkit.family.audio com.apple.developer.driverkit.transport.usb com.apple.developer.system-extension.install for the host application Restricted user-client access between the host application and driver I understand that the forum cannot grant an entitlement. I am trying to determine the appropriate process and whether manufacturer authorization is a prerequisite before submitting a formal request.

I've basically run the entire Apple website and couldn't find this information.

Dear All, I am currently developing a high throughput audio system which operates via PCIe tunneled into a USB4 interface. This include a custom FPGA based hardware and custom Audio DriverKit driver. While performing read operation via the hw DMA (that is a Host to Device transfer), I am noticing sparse latency spikes into the read transfers. Specifically, 4KB operations (which I assume including MRd + CpID) take normally from 5us to 40us to be completed, perfectly fine for my case. However, in some rare occasions, they can end up to 400us, which causes me overruns. The measurements have been carried out from the FPGA and they include the overall request and transfer time. While trying to tackle the problem, I'm investigating the possible power saving options and performance constraint methods at my disposal. I currently use these methods to mitigate the problem. ChangePowerState(kIOServicePowerCapabilityOn); SetPowerOverride(true); RequireMaxBusStall(kIOMaxBusStall25usec); CreatePMAssertion(kIOServicePMAssertionCPUBit | kIOServicePMAssertionForceFullWakeupBit, &ivars->PMAssertionID, false); The buffers are currently about 16MB, single segment, 16KB aligned and, of course, "prepared" for DMA. The system run for 3 hours without any overrun, but I'm not still fully convinced about its reliability. May someone provide me some comments on this? Are there profiling tools that I can use? Feel free to request me any required detail. The testing system is a MacBook Pro M2 Pro. Many Thanks and Best Regards Francesco

Dear Sirs, I’ve written a virtual audio driver based on AudioDriverKit and running as dext in my MacOS app. Sometimes when waking up from a sleep state the recording side of my driver extension seems to hang and I don’t see any calls to my io_operation callback. Then the recording app like a DAW seems to hang when trying to start a recording. This doesn’t happen after short sleep states or after a complete new start of my MacBook. I already opened a case in Feedback-Assistant on 5th of May (FB17503622) which also includes a sysdiagnose and a ktrace but I didn't get any feedback so far. Meanwhile some of our customers are getting angry and I'd like to know if there's anything I could do to fix this problem on my side. We’re not sure whether this worked in previous MacOS versions, we think we didn’t observe this before 15.3.1 but at least since 15.3.1. we’ve seen this problem. Best regards, Johannes

Dear Sirs, I'd like to add an icon to my audio driver based on AudioDriverKit. This icon should show up left of my audio device in the audio devices dialog. For an Audio Server Plugin I managed to do this using the property kAudioDevicePropertyIcon and CFBundleCopyResourceURL(...) but how would you do this with AudioDriverKit? Should I use IOUserAudioCustomProperty or IOUserAudioControl and how would I refer to the Bundle? Is there an example available somewhere? Thanks and best regards, Johannes

I have a custom USB Audio Class 2 (UAC2) compatible device. When I connect this custom device to a MacBook with a configuration of up to 10 channels (16-bit), everything seems to work fine. However, when I increase the channel count to 12, the MacBook does not recognize the 12 channels. It only shows the channel count as 0. TN2274 is the only source where I found some information about Apple's Audio Class Drivers, but it doesn't mention any limitations regarding channel counts. Could you let me know the current limitations of the Audio Class Drivers on the latest macOS versions? What configuration should I use to get 12 channels working? P.S. I also found that a 12-channel, 8-bit configuration is detected by the MacBook, bit I want it to work with 16bits. For more detail please check FB17098863

I need to implement a solution through an API or custom driver to completely block out the built-in speakers and microphone of Mac, because I need other apps to use specified external devices as audio input and output. Is there a way to achieve this requirement? What I mean is that even in system preferences, it should not be possible to choose the built-in microphone and speakers; only my external device can be used.

The presentation "create audio drivers with DriverKit" from WWDC 2021 demonstrates how to use a dext to implement a virtual audio driver. It also says " If a virtual audio driver or device is all that is needed, the audio server plug-in driver model should continue to be used". Indeed, in AudioDriverKit/AudioDriverKitTypes.h, there is no IOUserAudioTransportType Virtual, although CoreAudio/AudioHardwareBase.h includes kAudioDeviceTransportTypeVirtual. For one of our products, we require virtual devices to implement a software loopback "cable". We've implemented this using the "traditional" HAL plugin, and as a proof-of-concept, also using a dext. In the dext, I tried setting the transport type to 'virt', which seems to only have the effect of changing the icon shown in Audio Midi Setup. HAL plugins require an installer, and the installer has to kill coreaudiod in a post-install script. You have to turn off SIP to debug them. Just like AudioDriverKit drivers, they are out-of-process and run in a process not owned by the hosting app. Our HAL plugin's interface is property based; we had to write a lot of boiler-plate code to implement required properties. Writing an AudioDriverKit driver is in most respects easier - a lot of the scaffolding is implemented in the base driver, which we only alter where required. Debugging and installation is much easier. The dext works just fine, as far as we can ascertain, just as well as a HAL plugin. So, my question is - is the advice to use a HAL plugin for a virtual device still correct in 2025? And if so, what's the objection? We'd really prefer to ship the AudioDriverKit virtual audio device.

I am getting an unexpected crash from IOService::Create() when attempting to create a new user-client. The crash is a nullptr exception in OSCopyInObjects(). The last call from my code was IOService::Create(). As far as I can tell, all the input parameters to Create() are correct, and the Info.plist is has the correct key and class information - indeed, if I corrupt these I get an error status return rather than a crash. Any suggestions as to what could be causing this? I suspect that the problem may be related from a change in the underlying application that is creating the user client. This was modified from a standard app to a daemon, following the advice here: https://developer.apple.com/documentation/xcode/signing-a-daemon-with-a-restricted-entitlement. However, it is the driver that crashes - not the host opening the user client.

When My Usb interface working on recording， the sync is not good work. I found every IO will in_io_buffer_frame_size is same， it is not sync to UpdateCurrentZeroTimestamp. So The Audio driver Kit Read opration is not same like Write? What is the way sync with Usb in data? If only play audio with UpdateCurrentZeroTimestamp, it working fine. Thanks!

Hello, I'm developing a custom AU plugin that needs to connect to a DriverKit driver. Using the DriverKit sample (https://github.com/DanBurkhardt/DriverKitUserClientSample.git), I was able to get a standalone app to connect to the driver successfully. However, the AU plugin, running in a sandboxed host, isn't establishing the connection. I’ve already added the app sandbox entitlement, but it hasn’t helped. Any advice on what might be missing? TIA!

Dear Sirs, I've written an audio driver based on IOUserAudioDevice. In my IOOperationHandler I can receive and send the audio samples as expected. Is there any way to configure the number of samples transferred in each call? Currently it seem to be around 512 samples per call, which relates to 10.7 millisecs when operating on 48 kHz samplerate. I'd like to achieve something like 48 or 96 samples per call. I did some experiments and tried calls to SetOutputLatency() etc. but so far I didn't find the right way to change the in_io_buffer_frame_size in the callback. I'd like to do this as smaller buffer sizes would allow lower latencies for the subsequent audio processing. Thanks and best regards, Johannes

Dear Sirs, I've written an audio driver based on AudioDriverKit. In my audio callback function I'm receiving calls with io operation IOUserAudioIOOperationWriteEnd and IOUserAudioIOOperationBeginRead as expected which means I see IOUserAudioIOOperationWriteEnd operations during a playback in an application like VLC or the browser and I see IOUserAudioIOOperationBeginRead when recording in Audacity etc.. But when I open the SystemSettings and goto Sound and I select my driver as input I also see calls with IOUserAudioIOOperationWriteEnd which seem to be the just read input data. I can also watch this when starting up Teams. I think the purpose is to add the (mic) input also to the output so you have the chance to listen to yourself. Nevertheless I'd like to fully avoid this but I don't see a way to distinguish between the playback audio data and the input audio data inside this callback. How could I do this? Or even better is there a switch which would completely switch off these callbacks which forward the input to the output? Thanks and best regards, Johannes

Dear Sirs, when writing an AudioServerPlugin I can use the hosts WriteToStorage/CopyFromStorage functions to save and restore custom properties on restarting the machine. Are there corresponding functions for an audio driver based on AudioDriverKit? What would be the recommended way to save and restore properties so that they are available again after a reboot in an audio driver based on AudioDriverKit? Thanks and best regards, Johannes

Hello, now I need to make a control software for a multi-channel sound card device. The Mixing is implemented on the system through ASIO driver on the Windows side. Let's say I have an OUTPUT A channel and an OUTPUT B channel. On Windows I can share the audio from channel A to channel B so that I can hear it on channel B as well, even though I chose channel A as the playback channel. Now I need to implement this function on the mac, but I have not contacted the development of this aspect before, so I would like to ask whether Core Audio or driver can implement this function

Hi, I have an idea for an audio application. It does make use of HRTFs in a different way. So I would like to get the HRTF that was made for the user and use it in the application. Is that possible?

Dear Sirs, I've written a Swift App, a C++ application and a Driver Extension using DriverKit and AudioDriverKit. As it works on my development machine now I'd like to give it to some other users and so I'm trying to make a Release Build. I've created a Signing Certificate for "Apple Distribution" which I can use for my Swift App and the C++ application which also both use "com.apple.developer.driverkit.userclient-access". I've been given this entitlement and the "Distribution Support" is for "Development, Ad hoc, App Store, Developer ID". For my Driver Extension I'm using the entitlements "com.apple.developer.driverkit" and "com.apple.developer.driverkit.family.audio" which I've also been given and which show the identical "Distribution Support". But when I try to use my Signing Certificate XCode refuses to use the provisioning profile for the Dext and says "Xcode 14 and later requires a DriverKit development profile enabled for iOS and macOS. Visit the developer website to create or download a DriverKit profile." On the other hand I have to use the same Signing Certificate for my Swift App that embeds the Dext and the Dext itself. How can I create a Signing Certificate for Release mode that works for both, the Swift App and the Dext? Thanks and best regards, Johannes

Dear Sirs, I’d like to write a virtual audio driver that also exchanges data with a application and thus probably also offers a driver extension using IOUserClient. My first implementation was based on the sample https://developer.apple.com/documentation/audiodriverkit/creating_an_audio_device_driver and everything works fine and as expected on my development machine and I can install/uninstall the dext from within my application. But I had to learn that I will not be given the required entitlement com.apple.developer.driverkit.family.audio as AudioDriverKit seems to be not intended to be used for virtual drivers. So I found out that this sample should be used as starting point for virtual audio drivers: https://developer.apple.com/documentation/coreaudio/creating_an_audio_server_driver_plug-in. But this sample does not include a dext offering the IOUserClient interface which I think I need. The next sample I found was https://developer.apple.com/documentation/coreaudio/building_an_audio_server_plug-in_and_driver_extension . This doesn’t use AudioDriverKit and it includes IOUserClient so it seems to be a good start. Nevertheless it also requires some entitlements which are com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb. The client also probably needs the entitlement com.apple.developer.driverkit.userclient-access. Would I be given these entitlements for a pure virtual audio driver and why would I need com.apple.developer.driverkit.transport.usb? And is there a chance that AudioDriverKit will also be opened for virtual drivers as it seems to be a much more modern approach and doesn’t require a reboot for installing? Thanks and best regards, Johannes