Re: User-land CoreAudio driver and Leopard
Re: User-land CoreAudio driver and Leopard
- Subject: Re: User-land CoreAudio driver and Leopard
- From: Jeff Moore <email@hidden>
- Date: Thu, 8 Nov 2007 12:41:40 -0800
On Nov 8, 2007, at 3:50 AM, Brian Willoughby wrote:
On Nov 8, 2007, at 02:04, Stéphane Letz wrote:
> Can you explain a little more what this "coreaudiod" deamon is
about?
I would guess that coreaudiod is a daemon that owns all of the audio
processes, particularly the ones that execute the drivers running
the audio hardware. Because all applications share the audio
hardware and are mixed together, there must be another process to
own the final stage where all applications are mixed together. My
deduction is that this daemon process was formerly run by the user
who logs in at the console.
Coreaudiod's job is more mundane than that. It's there mostly to run
the System Sound Server and (new in Leoapard) to implement the server
side of the Audio Hardware Services API (both APIs are declared in
<AudioToolbox/AudioServices.h>).
The multi-client mixing is handled by the driver in the kernel the
same as it always has in OS X. There have been no changes in the
system in that area.
If correct, this might explain why iTunes audio stops when switching
users, although that did not happen in some OS versions before Tiger.
Actually, it is the HAL that stops doing IO in user sessions that are
frozen via fast user switching. You can see this behavior in any
application although iTunes may also stop IO on it's own as well though.
Now, with Leopard, I assume that the daemon is actually started
before anyone logs in, and thus is owned by a system user, not a
mere administrator or regular user.
This has always been true about coreaudiod, although we did make it a
proper launchd-managed daemon in Leopard.
Thus, if any part of your driver executed operations which are
affected by user permissions, then those operations might now fail
because the permissions have shifted to a different user.
This is definitely true and usually manifests itself at
bootstrap_lookup failures and other things tied to a login or
bootstrap session.
Sorry to spend all this space hypothesizing, but if I'm right, then
I think CoreAudio has just seen a great improvement.
You're right on some counts and a little off on others =)
There are some significant application classes which would be well
served by being able to run at boot time, before anyone logs in.
These are usually fixed installations that are permanently wired to
some kind of hardware, and need to be fault-tolerant enough to
operate correctly even when nobody logs in. Further, it would be
great to have audio tasks which would be able to function properly
and continuously even if someone logs out.
Believe it or not, this was all true prior to Leopard, at least for
IOAudio-based drivers. The proof is that we have been running the
System Sound Server out of coreaudiod for a long time now. However,
the running environment found in such a headless environment has
proven a bit challenging for some user-land drivers that assumed that
there is always a user session around.
--
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