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)? https://developer.apple.com/library/mac/technotes/tn2312/_index.html 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): https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24 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 On Mon, Apr 6, 2015 at 10:07 PM, Jeremy Friesner <[email protected]> wrote: > Hi all, > > I’ve written a little AudioUnit effects plugin that uses a semaphore and a > shared memory region in order to communicate audio data to/from a companion > application. (it does this because only the companion application has > access to all of the contextual information necessary to process the audio > properly) > > This plugin works fine under some 3rd party applications that support > AudioUnit effects plugins, but when I try to use it within GarageBand, it > fails to initialize. On investigation, this I found that it fails because > because semget() returns -1 and sets errno to EPERM. > > I’m pretty sure that is because newer versions of GarageBand run the > plugin code inside a sandbox for security reasons. > > My question is — is there any way to either get GarageBand to run the > plugin without the sandbox restrictions, or for my plugin to request > permission to use a semaphore and shared memory despite the sandbox? Or am > I just out of luck here? > > Thanks, > Jeremy > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/recapitch%40gmail.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
