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: Jeff Moore <email@hidden>
- Date: Thu, 08 Jan 2009 12:25:09 -0800
Yes. There could always be another daemon out there that wants to do
audio IO. You probably should change your plug-in's behavior to do
something smart when the bootstrap_look_up() fails.
The big catch is that the System Sound Server lives in coreaudiod. If
your device is the default device for a given user, then coreaudiod
will need to do IO with it because coreaudiod plays audio on behalf of
a user. If coreaudiod can't do IO, then system sounds won't work.
That said, if you are willing to live with that limitation, you can
make your plug-in do fake IO in the case where bootstrap_look_up()
fails. That way, the daemons will at least think things are working
correctly even though their audio won't be able to be heard. This
would allow other apps to still function normally with your plug-in
and daemon.
On Jan 8, 2009, at 1:12 AM, Stéphane Letz wrote:
------------------------------
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?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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