[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio

[Colin Guthrie]

Hi Taylor,

[ I've CC'ed a couple other potentially interested parties ]

'Twas brillig, and Taylor Hutt at 27/09/11 21:56 did gyre and gimble:
> 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.

Obviously we're somewhat biased here, but I think it would be prudent of
you to revisit some of the previous results. Pierre has done a lot of
work on the Intel side and numerous other companies are using PA in an
embedded space without any of the CPU problems you mention. There was
indeed a "period of pain" where such issue were caused, most typically
from the timer based scheduling mechanism that PA implements which many
underlying ALSA drivers did not play nicely with. Since then lots of the
driver issues were fixed.

Latest results have shown that PulseAudio will save you about 0.5w of
power for a "music player" type application. This is something that I
had presumed would be of interest for ChromeOS which is largely
targeting mobile platforms AFAIK. Saving power should be one of your
primary concerns.

Here are some links on the topic:
http://arunraghavan.net/2011/05/more-pulseaudio-power-goodness/
http://linux-tipps.blogspot.com/2011/04/power-performance-of-pulseaudio-alsa.html


> Since we have decided not to use Pulse, prior to my time, it seemed
> prudent to continue with that decision. 

I'll be blunt. This is a mistake. Revisit it. Do your own evaluation. We
know that the resources inside Chromium are somewhat tight. From
speaking to both the Chromium and Android guys at the ASOC conference in
Edinburgh, it was pretty clear that you wanted to be good players in the
open source community and also wanted to avoid duplicating effort and
didn't want to be burdened with maintaining another, in-house system and
would rather other people adopted it too. Well if you want to make use
of stuff that's out there you would do very well to look at PA.

> 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. 

This is a grave misunderstanding. PA copes *very* well with dynamic
devices. It's one of the key parts of what we do. Policy modules allow
things to happen automatically (for example when I have a voip stream
and I enable my bluetooth headset, a policy module kicks in and knows
that I want voip on bluetooth. This is all customisable, but at the end
of the day, this is very much a key part of the platform.

The fact that the power saving design is in the core of PA should be an
indicator that we're not really targeting the "static desktop" case but
rather covering a wide range of use cases.


> We've also looked at UCM and decided that it wasn't
> right for our purposes, at least in the present state.

FWIF PA will also support UCM in the near-ish future.

In either case, if you need UCM-like features, I'd strongly advise you
work with Liam and Mark to pursue this end - I really don't think
developing a in-house system here will help move things forward in the
linux audio stack. Both Liam and Mark (CC'ed) are very responsive and
will no doubt offer good advice and thoughts here.

> 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.

This is very much part of PA. Dynamic device selection is built in!! I
was even planning on developing a web based interface for this, keeping
ChromeOS in mind as it was my understanding you guys were switching to PA :s


> 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.

How does this relate to e.g. udev? PA currently integrates very nicely
with udev to handle all hardware device insertions and hotplug support.
We also integrate with avahi for network-based service discovery.

> 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.

This is good news as it means you still have time to make the right
decision. I strongly suggest you take some time to read up a bit more
about PA and chat to us about it.

Although quite old, you can probably get a good feel for the timer based
scheduling mode of PA from this article:
http://0pointer.de/blog/projects/pulse-glitch-free.html

It describes the timer based scheduling model inside PA that delivers
the power savings mentioned above.

Added to this the fact that we already have support for dealing with
passthrough data (which will be good for HDMI), networked UPnP devices
and Apple Airport devices (albeit the latter needs some work), and
you've already got a stack that will do what most of your consumers will
be demanding.

> 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.

I think that's quite dangerous. If you design device management in a
black box, in isolation, it could easily come out being quite
incompatible with how other people have solved the same problems and
thus just doesn't fit with lots of potentially very useful bits of the
stack. I believe you need to look more holistically at the issue. I'd be
happy to spend some time chatting on the phone if you want just to try
and give you a better picture of what PA is and what it does.


As most linux audio people will be in Prague (hopefully me too) during
October 24-28th, would there be any scope to you coming along? I think
it would be really beneficial to you to be there and meet everyone.
Hopefully this will be possible.


Cheers

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/