Accessing other audio devices from a user-land driver
Accessing other audio devices from a user-land driver
- Subject: Accessing other audio devices from a user-land driver
- From: Kyle Sluder <email@hidden>
- Date: Wed, 13 Mar 2013 21:17:32 -0700
I'm thinking about writing a user-land audio driver that acts as a
filter. I just want to affect audio on its way out of the system.
However, AudioServerPlugIn.h has this very big warning at the top:
"First and foremost, an AudioServerPlugIn may not make any calls to the
client HAL API in the CoreAudio.framework."
So that pretty much rules out sending my modified audio to the speakers,
doesn't it?
No matter, I'll write separate app that plays audio, and feed it data
via a shared memory region or some other low-latency data transfer
mechanism. But then there's this warning not too long after the
previous:
"Further, the host process is sandboxed… an AudioServerPlugIn may not
communicate with other processes on the system."
So… am I up the river without a paddle here? I really can't do anything
with the audio data other than send it to IOKit? What's the point of
having a user-land audio driver if I can't do anything with the data
other than send it to the kernel?
Well, the header comment _does_ say I can communicate with the network
if I add a special Info.plist key, but I'd really rather not send audio
data to my process via the loopback network driver.
Can I convince launchd to spawn an XPC service embedded in my CFPlugIn?
--Kyle Sluder
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden