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

[Mark Brown]

On Wed, Sep 28, 2011 at 10:02:49AM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Taylor Hutt at 27/09/11 21:56 did gyre and gimble:
> > Hello folks,

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

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

Yes, the general experience has been that Pulse does well in embedded
environments - power problems with it are pretty much always down to
issues in the drivers propagating up the stack rather than Pulse itself.
There's production hardware out there using Pulse which would really
notice.

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

I'd be slightly cautious about that number for embedded systems (unless
my back of envelope calculations are wrong 0.4W is on the high side of
the entire system power budget for MP3 playback on a smartphone) but the
general idea applies.  In general I'd say that the situation with Pulse
is that the audio streaming and DSP features (including mixing) are very
strong and there's sufficient win there to make them worth keeping,
reimplementing them is non-trivial.

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

I'll second this - there's a lot of work in Pulse that's far from
trivial to reproduce and pretty much all of the stuff that does need
doing is needed by everyone.

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

There is an issue around policy management for embedded systems (this is
what the UCM stuff is all about, we need a way to say what to do on the
various transitions) but in general the dynamic devices issue is very
important for desktop systems too.  They have to deal with things like
USB headsets and docking stations that appear and disappear as well as
all the stuff like Bluetooth which embedded systems have.  As Colin says
the policy for this is all rather more hard coded than is ideal right
now but it looks like this is the major issue in Pulse right now in both
desktop and embedded worlds.

The way the currently shipping systems I'm familiar with have dealt with
this is to layer a system-specific configuration module in which deals
with telling Pulse when to reconfigure, possibly in conjunction with
directly setting ALSA controls (one example I'm familiar with is doing
UCM calls in their system management daemon for example) and just
letting Pulse worry about the PCM streams.  This lets them get whatever
policy stuff they need to route data while still taking advantage of the
data flow code within Pulse.

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

I'd also second this; there's a lot of good stuff in Pulse and the
problem space is really very similar for everyone (both desktop and the
wide variety of embedded platforms out there) so the more we can all
pool resources to ensure that the infrastructure is good the easier life
will be all round.  Where there are problems there's generally going to
be more win in addressing them in Pulse than in starting from scratch.

A good way of looking at the current state of Pulse is that the work has
up until fairly recently been focused on building out the data path with
the configuration management taking a bit of a back seat (the idea being
that it should be able to figure something out by default that works
well for most systems).  The design has hooks to do something better
here, it's just that they've not been built out so much yet.