I know AVAssetDownloadURLSession is for HLS content, but I tried it with remote mp3 assets and it successfully downloaded them, albeit minus the "didLoad timeRange" and "didResolve mediaSelection", and the resulting .movpkgs did indeed contain the audio data.However, when trying to load the packages for offline playback, the asset cache reports isPlayableOffline as false.I tried masquerading the mp3 as audio-only HLS, but during download received the error -16655. Is there a way to make download and offline play of audio-only HLS or non-HLS audio work?

That is, will my render callback ever be called after AudioOutputUnitStop() returns?In other words will it be safe to free resources used by the render callback or do I need to add realtime safe communication between the stopping thread and the callback thread?This question is intended for both macOS HAL Output and iOS Remote IO output units.

I'm using USBDriverKit to write an audio driver for a High Speed USB device. In an attempt to understand the difference between DriverKit Extension and Kernel Extension latencies, I'm dispatching individual isochronous microframes that for this device each account for a duration 125µs, or 6 samples at 48kHz. I don't yet know what kind of latency I'm actually getting but I was surprised to see a high CPU usage of ~11% on a 512GB M1 mac mini running Big Sur 11.6. That's 8000 IsochIO() calls and 8000 completion callbacks per second. Instruments.app tells me that most of my time (60%) is being spent inside mach_msg, as part of a remote procedure call. Multiple questions occur to me: is this normal? should I expect lower CPU usage? isn't mach_msg blocking? shouldn't CPU usage be low? don't low latency audio folks avoid things like remote procedure calls? is seeking low latency throughput with USBDriverKit futile? does Monterey's AudioDriverKit enable lower latency, or is it a convenience API?

Xcode 14.0 beta (14A5228q) refuses to build a DriverKit extension's installer app unless the dext's bundleID a single . suffix added to the bundling app's bundle ID. The error is error build: Embedded binary's bundle identifier is not prefixed with the parent app's bundle identifier. Is this behaviour intentional? Maybe it makes sense for non-driverkit bundled things, but it breaks existing software, invalidates existing dext bundle IDs and leads to awkward bundleIDs like com.foo.installer.mydriver.

There is currently no way to "Bring your driver to iPad with DriverKit" because it's impossible to develop a driver because developers can neither deploy to the device nor run there because there is no way to procure development provisioning profiles with the required entitlements for actual hardware (USB, PCI). I bought an M1 iPad just to test this alleged new capability and the only thing it's good for so far is theoretically transferring files quickly or attaching some kind of ethernet dongle. My 1 month no-questions-asked returns window is going to close soon! FB10152280 FB10244398 FB10244627 FB10160665 FB10152361 FB10160793 FB10152210 FB10160567 FB10244046 FB10427776

I have a IOUSBHostInterface system extension that works great, however if I leave the device plugged in during a reboot, the usual driver is loaded instead and an un-plug + replug is required to load my driver. How can I fix this? It limits the usefulness of my driver.

There is no documentation for running, debugging and testing system extensions on iPadOS16. The WWDC 2022 session "Bring your driver to iPad with DriverKit" does not count because (as of beta 2) it is completely unreproducible. This document tells us that to test our system extensions we must disable SIP so it's clearly only for macOS: https://developer.apple.com/documentation/driverkit/debugging_and_testing_system_extensions It would be nice if this document were updated with reproducible instructions for testing system extensions on iPadOS! FB10427776

We're invited to write PCI drivers for iPad, but there's no capability for PCI Driver Kit in Xcode and a com.apple.developer.driverkit.transport.pci key in your entitlements does not find its way into your embedded.provisionprofile with Automatically Manage Signing nor can you manually add it in the appID portal, because it's not there. Huh?

You don't seem to be able to provision USB or PCI iPad DriverKit drivers, so I tried the null driver which requires only the driverkit entitlement, which can be automatically managed by the Xcode 14 beta. I can get it to deploy, but when it is enabled or when it matches, I see errors like "job failed to spawn," Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x105706980 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}} I wonder why that happens for me but didn't happen in the demo.