[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio
gmane at colin.guthr.ie
Wed Sep 28 01:31:59 PDT 2011
Just for reference, Taylor is not subscribed to the list (or wasn't
Taylor, if you are working on Linux Audio, I strongly recommend you
subscribe to this list, even if you are not using PA (which I'll write
to you about in a separate email).
In the mean time, please see Pierre's email below.
'Twas brillig, and pierre-louis.bossart at linux.intel.com at 28/09/11
00:39 did gyre and gimble:
>> 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,
>> was removed, and the sound system sat for a long while. The guy
>> in charge of sound decided to work on something else and I took the
> well that's too bad. I provided some pointers/patches to your colleagues
> over the summer... Most of the issues with high CPU utilization come from
> either resampling or bad latency configurations. With the relevant
> settings PulseAudio is actually fairly efficient.
>> 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.
> This is not incompatible with PulseAudio, Nokia had a similar solution
> with external Ohm modules to handle high-level device detection/policy,
> and PulseAudio handling the actual low-level routing/mixing.
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the pulseaudio-discuss