[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio
Tanu Kaskinen
tanu.kaskinen at digia.com
Wed Sep 28 02:28:39 PDT 2011
On Wed, 2011-09-28 at 12:02 +0300, Colin Guthrie wrote:
> > 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.
And if you need something that works *today*, Pulseaudio has pretty
comprehensive support for configuring alsa mixer settings even without
UCM (the mixer configuration support is used extensively in Nokia
products).
> > 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.
Pushing the routing policy to the applications doesn't seem like a good
idea. If Chrome will be the only application using audio then I guess
it's not a big deal which component has the policy code, but otherwise
doing policy in applications means duplication of effort, and conflicts
when different applications want to use mutually exclusive routings.
Chrome is used also on other platforms, and there the policy code will
be useless, and even harmful if it's not disabled (again, conflicts will
happen).
--
Tanu
More information about the pulseaudio-discuss
mailing list