I too would like to access the data for my own AirTags. I suspect that the decryption key for this is somewhere in the Keychain.

Also seeing this in /private/var/log/com.apple.xpc.launchd/launchd.log logs. It's contributing a truly excessive amount of disk writes from the launchd process. 300GB of data written by the process in the 5 days my computer has been running. Not sure about op but it's not related to an app I'm developing, though I noticed it in the logs while developing. I wasn't positive it wasn't my apps fault until I came across this post. my sw_vers: ProductName: macOS ProductVersion: 14.1 BuildVersion: 23B2073

CoreAudio's Hog Mode, kAudioDevicePropertyHogMode, or exclusive mode, is quite woefully under documented. This 5 year old forum post is one of the few references to it I found on Apple's domain. The only current Apple docs that mention it are here, and they say absolutely nothing: https://developer.apple.com/documentation/coreaudio/kaudiodevicepropertyhogmode That said, the comments in some SDK header files are helpful. See a snippet of that on StackOverflow here: https://stackoverflow.com/questions/39037794/on-macos-can-an-app-disable-suppress-all-system-audio-output-which-is-not-emitt You can also find a real implementation of hog mode in MPV's source code here: https://github.com/mpv-player/mpv/blob/master/audio/out/ao_coreaudio_exclusive.c And all that said, if you're not sure, you probably don't want to use hog mode. It's poorly represented to the user and there's only a very few niche use cases where it makes sense. Quoting this older post:  As one of the Core Audio engineers wrote answering a similar question "...why do you need hog mode for your app? Hog mode is a really unfriendly thing to assert on the system. As such, it should only be used in circumstances where it is essential like sending non-mixable data (such as AC-3) to the hardware. The vast majority of apps are best off pretending like hog mode doesn't exist.”