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

[Colin Guthrie]

Hi,

Mark has already posted a follow up, but I'll try and answer any
questions you posed that he didn't cover.

'Twas brillig, and Taylor Hutt at 28/09/11 18:29 did gyre and gimble:
>     > > 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
> 
> 
> That's not bad advice, but it's not always prudent. 
> 
> In this case, I am part of a team working to make a shipping product,
> and there are time constraints which
> do not afford the time necessary to do that, _and_ to make forward
> progress to get the sound system working
> across a constantly increasing variety of hardware. 

While I accept your standpoint, I'd also point out that PulseAudio has
been dealing with a variety of hardware for several years. We've got
extensive support for probing the many different kinds of mixer setups
to come up with a valid mixer element chain for volume controls and for
switching to different outputs (headphones vs. speakers, internal vs.
external mic etc).

If time is of the essence for you, I think it would be highly
adventitious to leverage years of experience from people rolling out
solutions to varying hardware and reusing a relatively mature bit of
software that already achieves probably 90-95% of what you'll need. To
me, that would seem like the must prudent approach to something with
time constraints. If anything I'd suggest the opposite would only be
true if there were no time constraints at all!


> The door has not categorically closed on Pulse for all time, but it has
> closed for the time being. 
> We've got a lot of work to get Chromium and Chromium OS to a point where
> ship with the desired features, and
> I don't presently have the time to re-investigate Pulse across our set
> of hardware.

I think that's a shame as we've already solved a lot of the problem
you'll encounter on that range of hardware. For problematic cases we
have mechanisms to allow specific configurations to be dictated
(specific mixer profiles attached via udev rules based on pci/usb ids).
It think that if you really do want to do a good job in this area you'd
do well to leverage the experience our community has built up. Even if
you do not actually use PA, the people in our community have extensive
experience you could leverage for advice. As I've mentioned a couple
times now you really should join our mailing list.

>     > > 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.
> 
> 
> Can you explain how Pulse copes with devices that have not been seen
> before and
> for which no configuration has been written?

The short answer is "it depends". Most of this stuff is modular so it's
really up to what modules you write and/or configure in your setup. At
present we have modules that implement a priority list based routing
system on a per-role basis. e.g. each application presents a role and
then the device to use is chosen based on a priority list specific to
that role. When a new device is plugged in we currently go on the
principle of least surprise, and as such it's added to the end of each
priority list. It would be very simple to change that to make it e.g. go
to the top of each priority list.

We do also have other modules that override this list. We have an
"intended roles" module which automatically matches up given streams to
given devices. e.g. if a device is classified as a handset or a headset
(i.e. some USB devices, Bluetooth devices etc) then they will be tagged
with an "intended role" of voip. This means that should any voip streams
come along, this device will be used.


It's also trivial to write other modules to do policy the way you want.
Moving streams around between devices is trivial.

> Does Pulse work with HDMI audio and video?

It works very well with HDMI audio. We don't touch video.

>     > 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.
> 
> Point me to the definitive documentation, please.

Most of the documentation is on our wiki. Sadly it's dog slow and
somewhat outdated. We are in the process of moving all the content
across to the Freedesktop.org wiki space, but this hasn't really been
fully planned yet so will take a month or so before it's ready I suspect.

http://pulseaudio.org/

Regarding stream management and moving stuff the doxygen documentation
lives here:
http://freedesktop.org/software/pulseaudio/doxygen/

Controlling device and stream volumes and getting info is covered here:
http://freedesktop.org/software/pulseaudio/doxygen/introspect.html

Sadly we don't yet have good docs written about moving streams around,
but pavucontrol is basically our reference design here that covers all
of the code needed to do this.

While most policy modules would typically be written inside PA itself
(due to the convenience of hooking into various events that happen (e.g.
when a new device is added/removed, or when new streams are started
etc.) there is nothing stopping you writing this kind of thing as an
external application (they can receive similar notifications). Just keep
in mind that any external program will be reactive rather than
proactive. i.e. if something is written as a PA module it'll be able to
know when a device has disappeared and then move any playing streams to
a new device. An external application won't be able to hook into things
at such an early stage and thus if it is deciding it's own device
preferences it'll potentially conflict with the device choice made
inside PA of the "rescued" stream and thus you may jump from an flat
battery BT headset to internal speakers (PA choice) to USB speakers
(external controller choice), whereas an internal module could move it
to the right device first time. This example is perhaps a bit convoluted
but hopefully I've highlighted the drawbacks of using an external app in
this regard. However, I should think that writing a module for PA that
uses the metadata and information from ADHD would be a pretty trivial
job. I think this was (approximately) what Mark was potentially
suggesting in his previous post.


There are also numerous blog posts by Lennart and myself and others,
which are now syndicated on the planet blog:

http://freedesktop.org/software/pulseaudio/planet/


In particular I'd like to point out (some now quite old):

http://0pointer.de/public/foss.in-pulse.pdf
http://www.vidarholen.net/contents/blog/?p=21
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/
http://0pointer.de/blog/projects/jeffrey-stedfast.html


There are of course some negative comments there too, but I think, on
balance, the negative criticism have mostly been addressed now (in a
large part due to driver issues as Pierre-Louis from Intel has already
pointed out regarding your previous problems - and I have to say it's a
real shame that we were not asked at the time about this as it would
have saved you a lot of headaches in the intervening period).


Anyway, I hope this reply has helped. As I offered to Leng Ooi a while
ago I'd be happy to discuss things on the phone if you like. I did this
before but this was probably more as a "recruitment" drive (possibly for
your role!) rather than the technical discussion I'd hoped for (I was
not and am not in the market for employment and/or relocation right
now), so perhaps this time around it would be more fruitful?

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/