I'm developing a low-latency USB audio-MIDI driver using AudioDriverKit and USBDriverKit for macOS and iPadOS. I've observed occasional delays in USB completion callbacks. The manufacturer's official macOS driver uses IOUSBHost to queue longer isochronous transfers and update their mapped OUT buffers as audio samples become available. I've reviewed the relevant IOKit and IOUSBHost documentation, but haven't established whether USBDriverKit supports an equivalent approach. Does USBDriverKit permit modifying portions of a CreateIOBuffer OUT buffer while an IsochIO request is still pending, specifically to supply audio for future USB frames? If so, what synchronization requirements and controller-prefetch guarantees determine the latest safe time to update those regions? If this isn't supported, is there a recommended alternative for maintaining low-latency isochronous audio despite delayed completion callbacks? Thanks.

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'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 am developing an iOS/iPadOS application containing an AUv3 Audio Unit extension. The standalone application icon displays correctly on the affected iPad. However, the AUv3 extension icon is not displayed correctly by any tested host on that device: AUM displays a red-X placeholder icon. Cubasis displays a small generic Swift-style placeholder icon. apeMatrix displays a generic AUv3 placeholder icon. The same TestFlight build displays the correct AUv3 icon on another iPad, and the icon also displays correctly on my iPhone. This therefore appears to be device-specific AUv3 extension icon registration or resolution failure rather than missing icon artwork in the submitted application. Troubleshooting already performed: Deleted and reinstalled the application. Deleted and reinstalled host applications. Restarted the iPad. Installed both local development and TestFlight builds. Confirmed the AUv3 extension contains its compiled asset catalog and icon metadata. Renamed the primary icon set from AppIcon to AppIconV2 and verified that both generated bundles used AppIconV2. Temporarily changed the AudioComponent subtype from Vped to Vpe2 and verified the generated extension plist contained Vpe2. Installed the newly identified component successfully. The AUv3 icon still failed in every tested host. The unchanged TestFlight build displays correctly on another iPad. Expected result: The AUv3 extension icon should display consistently in host applications, as it does on the comparison iPad and iPhone. Actual result: Every host on the affected iPad receives or displays a fallback placeholder instead of the AUv3 extension icon. TLDR - The key questions: Is there is a supported way to rebuild or clear the iPadOS AUv3 extension registration database without erasing the device? Is there any useful information available on Audio Unit extension registration, LaunchServices/icon-services database, or related iPadOS component-icon resolution on an affected device? Thanks.