13 May
2010
13 May
'10
1:29 a.m.
On Wed, 2010-05-12 at 09:20 -1000, Joel Roth wrote:
On Thu, May 13, 2010 at 12:01:00AM +0800, Ng Oon-Ee
wrote:
The catch-22 here is that for PA's autostart feature to work (and it has
to if things are to 'just work' on your typical Ubuntu install) there's
quite a few places where it needs to 'hook' in. This is a general Linux
thing, and because PA is not an app which the user is expected to
manually start, there's various autostarts for PA embedded in your
system.
Having a 'disable PA' button is fine, and I think Mandriva does it
(hearsay), but it adds a lot of burden on the maintainers. Do you
default your standard apps to PA support (which works better if PA is
running but doesn't work with standard ALSA at all) or to ALSA (which
hopefully runs the same both with or without PA, but doesn't then take
advantage of PA features such as sound-category-labelling). Should BT
headsets just not work once PA is disabled (previous method in ALSA
requires setting the ID in .asoundrc manually, will a script be written
to do that)? Does the 'disable PA' button also have to reconfigure all
audio apps such that they output to ALSA instead of PA?
And one of the reasons problems show up on PA when ALSA 'just works' is
that PA is using parts of the API which no-one else uses. Which is how
we actually got into this whole thread in the first place. So no, a
'disable PA' button wouldn't help to isolate things, but just reinforce
the notion that PA is causing the breakage. At the cost of additional
work and complexity (thus more room for bugs) for maintainers.
On Wed, 2010-05-12 at 09:14 -0400, Paul Davis
wrote:
I think that goes back to one of the problems with PA: that
some distros are not giving users a choice _not_ to use PA.
Users would be more open to experimenting and less prone
to snap judgments if they could have an easy way to
enable/disable pulseaudio, or perhaps some kind of
pass-through mode.
That would also help to recognize if problems are coming
from PA or from somewhere in the ALSA, driver or hardware
layers.
On Wed, May 12, 2010 at 8:58 AM, Philipp Überbacher
<hollunder(a)lavabit.com> wrote:
PA tries to do all of this at once, and at least on the
desktop it fails
often enough. Sure, many user complaints are old and the
problems might
be solved, but many users are fed up with it already and don't
ever want
to try it again.
The users that I have seen who are fed up with are generally people
who are trying to get JACK and PA to work on the same system with only
a single audio interface. The impression that I have (and it may be
wrong) is that users who don't try to do this are reasonably happy
with PA to the extent that ALSA works correctly for their Intel HDA
chipset. They get features that people have wanted for a long, long
time (device sharing, per-app sound control, switching output based on
jack-sensing status, on-the-fly device switching and more) and most of
this stuff works really well. The headaches seem to come mostly from
the same place that a lot of JACK user complaints come from these
days: poor/incomplete/hard to use HDA driver support.
The other group of people who are fed up are those who had problems with
the early PA-releases in various distros (Ubuntu mostly), solved them by
removing PA, and have since them removed PA on every install/upgrade. Of
course, this starts causing problems, which are then blamed on PA, even
though the original issues which caused them to want to remove in the
first place have been fixed.
Its amazing how single-minded Linux users can be over something like
this. Isn't a big part of Linux choice, flexibility, and all that?