Re: AudioUnit plugin vs. GarageBand sandboxing
Re: AudioUnit plugin vs. GarageBand sandboxing
- Subject: Re: AudioUnit plugin vs. GarageBand sandboxing
- From: Christian Rober <email@hidden>
- Date: Mon, 06 Apr 2015 23:07:18 -0400
Hi Jeremy,
Interesting question; I was just working on socket communications between my OSX hosted audio unit and my other parallel app...
First, have you seen this doc (and associated children docs)?
I noticed that you can add plist items to declare the use of certain kernel features. Maybe if you add the right key Garage Band (or the kernel) will change the permissions at runtime? Or it may just block your AU outright, which would at least corroborate your other observations. It may be worth following one of the guides that shows you how to variously re-sandbox AULab and probe it in the debugger with your AU attached.
You may have already seen this (bottom of doc):
My reading: Unless there is some way to use Garage Band's group name, and use only POSIX shared memory, then your design does not seem possible with a sandboxed host. Have you tried determining GB's group name and adding that entitlement to your secondary app? Assuming the semget error is occurring in the AU, there may still need to be some symmetry between the GB process and your secondary app.
My other thought is that plain old sockets would be too slow for audio rendering cycles, otherwise you would have tried them already. They may have the same issue though without entitlements added.
Lastly, regarding the documentation: I have never tried creating an XPC service. I assume it would need to be created by the owners of a given signed/sandboxed app (i.e. Garage Band), and there would have to be a host-provided, corresponding library/SDK to link your AU against. But that is just a guess, and a service may be too slow compared to typical shared memory access for your needs.
Hopefully someone who has more experience with sandboxed audio IPC can jump in...?
--Christian
_______________________________________________
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