Hi Kevin, Thanks for the clear info. Here's a follow-up after extensive driver testing on macOS (M1 Max, macOS 27.2). In normal operation, my 1 ms OUT requests are submitted 13–16 ms ahead of the controller. In the two incidents I've captured in detail, the next audio had already been published about 14 ms early, but the dispatch queue that submits requests wasn't serviced for roughly 8–10 ms (inferred from event timing), and the next request then missed its frame. For reference, the vendor's own macOS driver on the same Mac (a Core Audio HAL plug-in that uses IOUSBHost, as I mentioned in the other thread) shows 4.58 ms round trip at a 32-frame buffer, 5.92 ms at 64 frames, and 8.58 ms at 128 frames (as reported by the DAW, not verified as true RTL, but certainly in the ballpark), so the hardware isn't the limit. That leaves me with three questions I haven't been able to resolve through testing and research: You mentioned the audio system typically writes 2–4 ms ahead of the bus; stalls of 8–10 ms are well beyond that. What determines how long a DriverKit dispatch queue can go unscheduled, and is there a supported way to bound it (for example, a QoS or priority setting)? Should I expect the same dispatch and scheduling behaviour on iPadOS as on macOS? The iPad Pro (M1) is the eventual product target. A request whose first USB frame is only 1 frame ahead of the frame number I read from the OUT interface with GetFrameNumber just before submitting is rejected as IsoTooOld, while 2 frames ahead has been accepted. Is there a documented minimum lead for IsochIO, and is GetFrameNumber the right current-frame source to compare against (as opposed to CurrentMicroframe)? I can share the recorder exports if that would help. Thanks again, Luke

For context, the device that I'm building the driver for is a BOSS SY-1000 Guitar Synthesizer, with eight channels of 32-bit audio input and eight channels of output at 48 kHz, alongside two MIDI ports. Yes, I meant 32 ms requests, each containing 256 high-speed microframes at 125 µs intervals. So the actual USB packet cadence remains 8,000 per second, rather than approximately 31 transfers per second. Thanks for your clarification about controller ownership. I had been treating the individual scheduled microframes within a pending request as independently writable, but I now understand that the controller's handling of the entire DMA buffer after the request starts isn't guaranteed. I've consequently revised the implementation to use shorter, 1 ms isochronous OUT requests, with each payload finalized before submission and left unchanged until completion and safe retirement. Initial physical testing confirms that this arrangement is functioning, although I'm still working through some unrelated input-continuity problems. Thanks again for taking the time to explain all this. Your insights have been invaluable to this newb! Regards, Luke

Thanks, Kevin. Your explanation has helped clarify the intended architecture. To explain my earlier synchronization question: I'm using 32 ms isochronous OUT requests containing multiple scheduled microframes, with audio data written into the mapped buffers as it becomes available. I was trying to establish whether the payload for a later microframe can still be updated after the request has begun transmitting, provided that particular microframe hasn't yet been sent. In other words, does the safe-update boundary apply to the entire request or to each scheduled microframe? I'm asking because this distinction affects how closely to transmission I can safely supply audio without increasing latency. Thanks again, Luke

My larger concern was the lifetime of the driver-owned resources accessed by the audio callbacks, rather than the lifetime of the handler block itself. The callbacks access shared driver state and audio buffers, while the USB transport has separate asynchronous completion and cancellation requirements. I wanted to ensure that teardown could not release those resources while an audio callback was still accessing them, without introducing blocking operations on the real-time thread. Your explanation that IOUserAudioDevice retains the handler until I/O has definitively stopped, together with the service termination ordering you’ve described, clarifies the framework’s ownership responsibilities. That should help ensure the driver’s own USB resources and state are retired safely before completing service termination. Thanks.

As a first strike, I've completed some additional physical testing to investigate whether the audio publication failure could be caused by retained device state or the absence of a reboot. The results are consistent across two independent M-series iPads: M1 iPad Pro: The USB transport configuration continued to fail after a full reboot. The SY-1000 did not appear as an audio device in the DAW/host. M3 iPad Air: I repeated the test on a second iPad that had never previously had the driver installed. Both the Audio and MIDI DriverKit extensions installed and activated successfully, but the SY-1000 again failed to appear as an audio device in the DAW/host. For comparison, the Thunderbolt transport configuration continues to provide functional eight-channel audio on the M1 iPad Pro. These results make retained device registration or the absence of a reboot less likely explanations. The underlying difference in audio publication remains unresolved. Regarding your other observations: Unexpected DEXT termination: I haven't yet established why the extension appears to terminate while the USB device remains physically attached. I agree that this behaviour warrants investigation independently of whether Core Audio successfully publishes the device. I/O Registry: A complete comparison of the working and failing configurations, including the services above the driver and their state throughout attachment and removal, remains to be completed. Console logs: I also agree that identifying the first meaningful divergence between the two configurations is important. I haven't yet isolated a definitive divergence that explains the publication failure. Given these outstanding questions, I intend to follow your recommendation to investigate the same DriverKit implementation on macOS. This should provide better visibility into service attachment, termination, the I/O Registry hierarchy and Core Audio publication, while also helping establish whether the behaviour is specific to iPadOS. One practical concern I'd like to mention is that this approach can be quite restrictive for independent developers without access to multiple Macs. In my case, I already have the manufacturer's fully functional SY-1000 driver installed on my development Mac. Isolating that driver and switching between configurations introduces additional complications and risks disrupting an otherwise working audio environment. I certainly appreciate the diagnostic advantages of macOS, but I wanted to highlight the practical difficulties involved. The ultimate objective remains a functional iPadOS driver, but using macOS as a diagnostic environment seems to be the most logical next step. Thanks again for your time and insights.

***AUM = the host iPadOS application that the driver serves audio-MIDI to.

Thanks, Kevin. First, to answer your IOMatchCategory question: yes, both DEXT personalities originally included private matching categories. I've removed them, and subsequent controlled physical tests confirmed that both drivers attach to their intended USB providers with exclusive ownership. However, changing the advertised audio transport type from Thunderbolt to USB still prevents the device from appearing in an audio host/DAW. I've posted the detailed results in the USB transport thread. Regarding service termination, I'm planning to restructure Stop() so cleanup proceeds asynchronously after the subclass method returns, with superclass Stop() called exactly once after cleanup. I understand that returning Busy does not request a retry, and that StopDevice/StopIO should not be assumed to drain outstanding audio callbacks. One AudioDriverKit ownership issue remains before I can implement this safely. Our IOUserAudioDevice registers an IOOperationHandler that accesses cached audio mappings and driver-owned state. I'm considering an independently owned context captured by the handler, with atomic admission control and an in-flight callback count. However, even callbacks rejected by admission control must first access that context, so counting admitted callbacks alone cannot establish its safe lifetime. Could you clarify two points? Handler lifetime: Does AudioDriverKit guarantee that an invoked handler block and its captured context remain valid from before callback entry through return, even if the IOUserAudioDevice is concurrently released or reset? Retirement and reclamation: Is there a public completion point establishing that no further handler invocations can begin and all existing invocations have returned? Can AudioDriverKit release its last reference to the handler block on a real-time audio thread, potentially destroying captured objects there? If no public retirement mechanism exists, what ownership pattern does Apple recommend for safe, non-real-time reclamation, including incomplete teardown or cancellation? I'm not assuming that StopIO, RemoveObject or superclass Stop() establishes callback retirement. A supported ownership pattern or reference implementation would be extremely helpful. If this requires a more detailed code-level DTS investigation, please let me know. Thanks, Luke

Thanks, Kevin. The USB transport and service-termination discussions have become a little intertwined, so I'm responding here to the IOMatchCategory question in your latest reply in the IOService::Stop thread, to keep the USB transport findings together. Yes, both DEXT personalities in the original build associated with FB25067968 included private IOMatchCategory values. I've now read your DEXT matching guide and the relevant IOKit Fundamentals documentation. You're right that these categories were inappropriate for the USB providers. I've since removed both categories and completed two controlled tests on the iPad: Setup108: With the categories removed and Thunderbolt still advertised as the audio transport type, both DEXTs attached to their intended USB providers. The registry showed exclusive ownership with no additional attached driver in the captured SY-1000 subtree. Audio appeared in AUM and worked correctly, as did MIDI. Setup109: Starting from that working source, I changed only the two AudioDriverKit transport declarations from Thunderbolt to USB, apart from build identifiers. Both DEXTs still attached correctly. Audio initialization, AddObject, RegisterService and HAL user-client connection succeeded, and MIDI remained available. However, SY-1000 disappeared from AUM, with no StartDevice, StartIO or audio transfers recorded. To clarify my original report, the physical connection has always been USB through Apple's USB-C adapter. Only the AudioDriverKit transport-type property changes between these configurations. The private matching categories were therefore a genuine configuration mistake, now corrected, but the latest evidence suggests they do not explain the remaining USB-advertised audio-visibility failure. I have retained I/O Registry snapshots and sysdiagnoses for both tests. Given that the intended driver attachments and HAL connection succeed in the failing configuration, is there a particular AudioDriverKit/Core Audio publication or routing requirement you would recommend examining next? I'll keep the remaining IOOperationHandler lifetime question separate from this investigation. Thanks again, Luke

Thanks, Kevin. Understood—cleanup can continue after Stop() returns, and calling super::Stop() signals completion. Could you clarify the AudioDriverKit-specific step needed during that cleanup? Is it supported for the driver to initiate StopDevice directly during service termination? If so, does completion of the resulting StopIO sequence ensure that no further IOOperationHandler invocations can begin and that existing invocations have returned? If that sequence does not establish this synchronization point, which AudioDriverKit operation should be used before the audio buffers and the handler’s supporting resources are released?

Thanks, Kevin. The retained filtered console export shows a more specific failure during initialization. With USB transport advertised, the driver registers successfully, HAL connects, and Core Audio accepts the audio formats. The subsequent route-construction path in audiomxd/VirtualAudio.plugin logs Unhandled UID for the SY-1000 audio device, followed by 'who?' (kAudioHardwareUnknownPropertyError). Audio I/O never starts. The log does not identify the property involved. A comparison build was made using the same toolchain, with only the two transport assignments restored to Thunderbolt, apart from version stamps. Audio visibility returned and I/O could start, although other startup reliability issues remained. Does that error sequence suggest a particular property or registration requirement that should be checked? The original .logarchive could not be located, but the filtered console export from that capture has been preserved. I have attached it directly to this reply as four numbered .txt files, each under 10 MB. The split preserves complete log records, and the files can be read individually or concatenated in numerical order. The related Feedback Assistant report is FB25067968. Also, what is the recommended way to capture an I/O Registry snapshot from the iPad?

For reference, the icon cache error resolved after updating to a new iPadOS software version (26.5.1→26.5.2). Notably, a few days ago I tried reinstalling iPadOS 26.5.1 via USB connection to a macOS device, but that didn't solve the problem.