[PlanetCCRMA] uninstall pulseaudio to increase audio-app stability across updates (was Re: yum update)

[Niels Mayer]

Regarding private reply re my "do i dare upgrade to sp3 vs linux"  -- yes
Linux hasn't exactly been good for audio stability after major upgrades, in
the last few years; there's been lots of breakage introduced by changes in
9->10->11->12. I place the blame squarely on pulseaudio. Fortunately, fedora
is quite customizable, and one of the main customizations I do for any
workstation that does audio is to totally remove pulseaudio. An addition to
linux that IMHO has been a huge setback, along-side the kernel graphics
modesetting blunder just to get rid of a little scrolling text (which I
disable at boot with "nomodeset"). With those two customizations alone, one
video, one audio, I've saved myself countless upgrade problems over the
years. I'm sure if someone took statistics of issues caused by those
features, it would account for a significant portion of all total bugs in
Fedora.

To get closer to audio nirvana, see
http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workaroundssection
and follow section "To really remove PulseAudio for some reason"...
furthermore you'll want to follow these notes from a bug I need to file:

(08:31:46 AM) ***npm the proper way to uninstall pulseaudio is (1) in sound
> preferences select "no sounds"; (2) in gstreamer-properties, setup specific
> ALSA devices ; (3) 'yum remove alsa-plugins-pulseaudio
> pulseaudio-module-gconf pulseaudio-module-x11 paprefs pulseaudio
> pulseaudio-module-lirc pulseaudio-module-jack pulseaudio-utils' ; (4)
> reboot...

(08:32:20 AM) npm: if you skip step #1, you get a system that doesn't
> respond to mouse clicks in a timely fashion (bug)

(08:32:46 AM) npm: and it takes a minute to switch screens in windows panel
> (bug)

(08:33:23 AM) npm: so either the pulseaudio dependency should be properly
> reflected so that you can't uninstall pulseaudio w/o uninstalling all of
> gnome

(08:33:31 AM) npm: or the bug should get fixed


Regarding the role of pulseaudio in "not being helpful to the cause", note
this extremely interesting excerpt from
http://opensourcemusician.libsyn.com/index.php?post_year=2010&post_month=01

Pat of The Linux Link Tech Show made an interesting post to his blog about
the current state of linux audio. To quote the beginning excerpt from his
blog"So sound issues STILL plague Linux in general. I think we can all agree
that the decision to make Pulse Audio the default sound daemon in Linux has
resulted in mixed results at best. While the creator of Pulse Audio has
repeatably claimed the issue was entirely the fault of Linux distribution
maintainers for not implementing it properly it still continues to be an
eyesore more than 3 years since it was first introduced."Pat reminds us that
back in 2005, Linspire was using Jack audio as the main sound server.To
quote from the final section from Pat's post"Mark Shuttleworth should hire
Paul Davis, the programmer who wrote JACK and Ardour. I guarantee the
current audio issues in Linux would be resolved in under a year and for
good. The only major challenge would be implementing a simplified
configuration out of the box that 98% of users would be happy with. The
remaining 2% could go to the “advanced” settings and do their multi-track
recording."

Discussion
Pat's full post can be read here:
http://pdavila.homelinux.org:8080/blog/?p=369OSMP asked Paul Davis to
respond to the content of Pat's blog post.Paul's response was that he
thought the post was sweet, but answered pragmatically he has discouraged
the use of Jack for Desktop audio use. I asked Paul to clarify, and he
stated quote "Jack doesn't provide 30+% of what desktop audio needs" End
quote.Steve then asked Paul, "In a perfect world, money and politics aside,
would you like to see the whole Linux audio stack (basic and advanced) to be
done on Jack?Paul response was - Quote "Yes, in that perfect world, that's
about right, alas, we don't live in that world." End Quote.Paul went on to
say - Quote "More precisely, I'd like to see

         (a) ALSA slightly redesigned so that it could easily be used for
low latency & low power situations with equal ease, and even at the same
time.

         (b) An application layer library that provides blocking i/o for
apps that don't want to do callback driven i/o.

         (c) Some way for JACK to do re-sampling.

         (d) A resolution of the netjack mess and way to get that working
with huge ease.

         (e) Something very much like JACK at the core of it all.
Paul at this point gave respect to Lennart's efforts with Pulse audio
stating Quote: "Any attempt to fulfill the same role (as pulse) is going to
run into the same issues. Part of the reason why JACK "Works" is because
JACK sets the rules; Pulse tries to let apps set the rules and works with
them as much as it can." End Quote.Steve asked Paul if he thought the root
cause of PULSE audio's challenges was ALSA?Paul state - Quote "Not directly,
ALSA is an extremely flexible HAL (hardware abstraction layer) that has
allowed people to continue to write apps using very different strategies for
audio i/o. It has also continued to support the old OSS API in addition.
This means that the Linux audio landscape is littered with hundreds of
applications each of which can have its own little quirks... ALSA is great;
applications using ALSA is not so great." End Quote.Dan asks Paul: In your
opinion, do you think that pulse is going to resolve the issues with desktop
sound currently plaguing Linux?"Paul responds - Quote "I believe that it
*could* - I'm agnostic about whether or not it will." End Quote.Steve then
asked "Would the ALSA overhaul you suggested earlier replace jack and pulse
or would they still be required but work better on that stackPaul responded
"The stack would just be more integrated it would still be ALSA. there would
be something a lot like JACK. there might or might be something like Pulse
depending on what you think pulse is. Lennart and i have actually talked
about the ALSA part" End Quote.
-- Niels
http://nielsmayer.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/planetccrma/attachments/20100302/b590e95b/attachment-0001.html