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
cvarenc
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
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.”
AppleMobileBackup seems like it'll work on the on the cli, but it actually doesn't.
It has this really awesome help page that lures you in:
$ /System/Library/PrivateFrameworks/MobileDevice.framework/Versions/Current/AppleMobileDeviceHelper.app/Contents/Resources/AppleMobileBackup --help
Action (one required):
	-b, --backup						 perform a backup
	-r, --restore						perform a restore
	-E, --erase							erase target device
	-C, --change password		change backup password from the given old password
	-e, --extract path			 extracts a relative path to the current directory
	-R, --remove path				removes a relative path from the backup
	-f, --filename path			prints the filename in a backup of a relative path
	-i, --info							 display info about a backup
	-I, --create-info				create a placeholder Info.plist file
	-l, --list							 list the contents of the backup
Options:
	-d, --device deviceid		device identifier (defaults to lockdown)
	-t, --target deviceid		target device identifier
	-s, --source deviceid		source device identifier
	-P, --password password	optional password when changing password or extracting files
	-N, --no-pass-prompt		 ignore terminal prompt for password
	-D, --domain name				domain name for --extract (default "HomeDomain")
	-q, --root path					root backup directory
	-o, --output path				output file for action (not logging)
	-h, --help							 print this message and exit
But I haven't gotten it to do anything with my encrypted backup. Very silent when it errors. Though if you check the console log you'll get slightly more insight.