Pulse audio

Daniel Chen seven.steps at gmail.com
Thu Oct 8 12:40:33 UTC 2009

On Thu, Oct 8, 2009 at 8:14 AM, Vincenzo Ciancia <ciancia at di.unipi.it> wrote:
> The real problem that nobody seemed ever to be getting is that when you
> introduce huge regressions, then you probably should 1) either not
> distribute the software yet 2) or put more energy into bug fixing for
> the particular software, or at least have strong, or 3) have convincing
> reasons for forcing people to "enjoy" the regressions while they could
> as well live happily with the previously used one, or 4) make it easy
> for people to try the new solution, and if it fails, revert to the old

All valid points, but:

(1) is a catch-22: software does not get fixed if no one uses it. You
need real, difficult bugs to be reported, i.e., real testing.

(2) requires that clueful people dedicate resources. Resources are not
just economic. As I've stated previously, finding people who know the
stack intimately is nontrivial.

(4) has always been possible. It has always been easy to use
PulseAudio and discover its integration deficiencies. It has not
always been easy to disable PulseAudio, but it certainly remains
straightforward for a savvy user:

touch ~/.pulse_a11y_nostart
echo autospawn = no|tee -a ~/.pulse/client.conf
killall pulseaudio

> video calls. I never succeded in having it work for voice/video. And it
> is so badly broken in other areas I really wonder how you all can be so
> blind.

You seem to use "you all" as if you can't effect change within the
source development.

> Asking users to start contributing proves that there is no sufficient
> manpower to fix bugs. But perhaps people could live without the new
> software and related regressions? Now in the case of pulseaudio, for me,

There has always been a manpower issue. Realistically, people need to
step up. I'm a bit tired of spending all my free time doing this for

Living without PulseAudio is possible, but which bugs would you
prioritize? For instance, how easily would you find bugs in alsa-lib
and linux if you don't have hard but useful test cases? Empirically,
not easily at all. Significant bugs in both alsa-lib and linux sat
undiscovered and unfixed for _eleven years_ before PulseAudio finally
revealed them.

> But are there experimetnal measurements of the impact the introduction
> of pulseaudio had in hardy on users? Empirically, I saw that it broke
> skype for everybody I knew.

No need for experimental; just look at all the bug reports filed
affecting flashplugin-nonfree, nspluginwrapper, firefox-3.0, alsa-lib,
and pulseaudio. The sad thing is that we could have shipped a two-line
change to /etc/pulse/default.pa that would have alleviated nearly all
of the (users') showstoppers. The change remains in my
pulseaudio/hardy bzr branch.

Skype fundamentally misused the alsa-lib API. PulseAudio "broke" Skype
is a horrible non-example.


More information about the Ubuntu-devel-discuss mailing list