Re: OSX 10.5.6 breaks our user-land driver
Re: OSX 10.5.6 breaks our user-land driver
- Subject: Re: OSX 10.5.6 breaks our user-land driver
- From: Stéphane Letz <email@hidden>
- Date: Thu, 8 Jan 2009 10:12:01 +0100
------------------------------
Message: 10
Date: Wed, 07 Jan 2009 14:27:46 -0800
From: Jeff Moore <email@hidden>
Subject: Re: OSX 10.5.6 breaks our user-land driver
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Yes. We use bootstrap_look_up directly in our client processes to look
up the registration port of coreaudiod by name.
The only catch in your case is that your plug-in in coreaudiod is
going to want to call bootstrap_register() in order to set up the
mapping between your name and your port. Unfortunately,
bootstrap_register() is deprecated. In coreaudiod's case, we avoid
this problem by having launchd manage the name to port mapping.
You can't do that in your case since you don't control the launchd
plist for coreaudiod. One thing you could do though, is create a
separate launchd daemon whose sole job is to map names to ports. You
could think of it as a private bootstrapping service. Whenever one of
your plug-ins was instantiated, it could message this daemon to map a
name to a port in the process the plug-in is in. It could then also
message this daemon to look up a port by name.
You could also move your daemon that is living in the user session
that your plug-in in coreaudiod is looking for out into the global
session. The complication here is that I imagine that the reason you
do a per-user daemon is that you are using that as a way to scope any
per-user state. Moving the daemon out to the global session would
entail retooling your daemon so that it can manage connections from
multiple users. One way to do that would be to have a session based
approach where each user logged into the daemon and the daemon managed
the per-user state as it changed implicitly. Another way would be to
make sure that any necessary per-user data is always sent along with
each IPC message. I prefer to use the latter approach where possible
because it is, in essence, a state-less connection and so requires a
lot less support in the server.
Thanks for your detailed answer.
Changing our server to run in the global context is probably a lot of
work. Since what we are interested in the first place is having our
user-land plug-in be available as the default audio device, I am now
thinking of an alternate possible solution.
The idea would be to have a "fake" version of the user-land plug-in
that would be visible for "coreaudiod" process: that is this fake user-
land plug-in would not need to connect to the server but would just
show all essential parameters (plug-in name and UID, possible channel
mapping... etc...) to coreaudiod, so that coreaudiod does it job of
keeping this device as the default one.
Do you think it would be a viable solution?
Thanks
Stephane Letz
_______________________________________________
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