Google ChromeOS reinventing the wheel, ignoring PulseAudio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 27, 2011 at 8:16 AM, Tanu Kaskinen <tanu.kaskinen at digia.com>wrote:

> On Tue, 2011-09-27 at 18:02 +0300, R?mi Denis-Courmont wrote:
> > Le mardi 27 septembre 2011 17:27:14 Arun Raghavan, vous avez ?crit :
> > > Do you have any more details? Seems to be more of a policy daemon than
> > > an audio server.
> >
> > Isn't audio policy daemon just a fancier name for (modern) audio server?
> > Does PulseAudio not implement audio policy?
> >
> > Sure, PulseAudio certainly does not police video devices. That's partly
> done
> > by the X server (XVideo grabs), partly by the window manager, but mostly
> not
> > done at all.
> >
> > But still...
>
> Looking at what there is currently, there doesn't seem to be any trace
> of a client interface. That would suggest that it won't handle the
> actual audio stream data. Of course, the project is in a *very* early
> stage, so the client interface bits might get added later.
>
> In order to replace speculation with actual facts, I'll CC Taylor Hutt,
> who seems to be doing the development. Taylor, would you possibly have
> time to share some information about ADHD? For convenience, here's a
> link to the beginning of this thread:
>
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011452.html
>


Hello folks,

I am indeed the one doing the majority of the work on the ADHD system at
present, and I can answer questions about it.  As a bit of background,
PulseAudio was attempted for a while before my time on the Chromium OS
project.  The results for some of the hardware we have were not very
inspiring -- at idle, I was told Pulse would take 30% of the CPU.  So, Pulse
was removed, and the sound system sat for a long while.  The guy originally
in charge of sound decided to work on something else and I took the
responsibility.

Since we have decided not to use Pulse, prior to my time, it seemed prudent
to continue with that decision.  As far as I understand it, Pulse also
doesn't cope well with dynamic devices -- it's more suited to a desktop
system than to a system which will have devices dynamically inserted &
removed.  We've also looked at UCM and decided that it wasn't right for our
purposes, at least in the present state.

Since it's expected that Chrome machines will have devices dynamically added
and removed, we needed to be able to adapt to those dynamic events, and
respond in a manner which will allow the user to select the output & input
device -- think of this as a problem similar to printing: if you've got more
than one printer available to your system, and you want to print a document,
the computer cannot easily decide which printer you wish to use at all
times.

ADHD is the name of the Portage project, and gavd is the name of the daemon
that runs.  There will probably be other aspects to ADHD as time marches on,
but right now it is just the daemon.

gavd is not a policy daemon.  The purpose of gavd at this point is to
monitor for new hardware, removed hardware, and things being plugged into
the on-board minijacks.  Presently, gavd is only going to be dealing with
audio hardware, but it is believed that it will ultimately subsume the
management of video output, particularly HDMI.  At present, the HDMI output
is handled by the power management daemon.

gavd will maintain information about the currently installed hardware and
provide that information to Chrome, and Chrome will probably end up making
the policy decisions about the output device to use, maybe based on some
type of input from the user.

At present, all this is in flux, and the final direction / ultimate goal has
not been codified.  I'm currently working to get enough infrastructure built
up in gavd so that we can start experimenting with changes that will be done
in the rest of the system.

In short, gavd is not attempting to do what Pulse does, nor is it trying to
replace UCM.  Rather, it's a solution for our special needs.

At some point in the future, I can envision a way that we might able to use
UCM to switch between different configurations, or even to use Pulse Audio.
But for now, we've got to resolve various software issues in the project so
that all parts of the projects are on the same page.  Once everything is
aligned with respect to device management, then we can decide what comes
next.

thutt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110927/9b35b42f/attachment.html>


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux