[pulseaudio-discuss] Pulseaudio in general - does it make sense?

Colin Guthrie gmane at colin.guthr.ie
Mon Dec 21 02:36:38 PST 2009


Hello once again.


As an opener to your mail I will point out that at no point to you refer
to any of the technical reasons as to why PA adoption is a good thing.
All you do is point out the fact that you've had a few problems (and as
someone at the front line of PA support and distro roll out, I can
certainly say you've had many more problems than most users and I
sympathise with that).


'Twas brillig, and Markus Rechberger at 21/12/09 00:14 did gyre and gimble:
> I was using PA for around 1 1/2 years now. My feedback:
> 1. I asked for some help which worked out fine at the beginning
> 2. problems grew and are still growing .. I'd still get some help but
> I just want to have my stuff work and I'm not interested in playing
> debugger with Ubuntu anymore.

Well sadly without feedback for bugs there is very little we can do to
improve the situation. You quite frequently pop by on #pulseaudio IRC
and basically dish out rhetoric about xyz being broken. I don't doubt
you for a second, but all the times I've asked you for test cases, debug
output coredumps and backtraces you've just ignored the request and
carried on complaining (in fairness there is one "test case" on the
mailing list you posted but it's just code snippets, not a running app,
so I'll have to find time to code it up into an app to test it).

I don't want to be rude, but without proper feedback, complaining and
moaning does precisely nothing - other than generally annoy the people
who give up their own time to try and help you (which IIRC is a
commercial endevour - so people are quite literally giving up their
personal time to help you and your company do well - please keep this in
mind!)


> 3. We use to sell devices which are supposed to play back some Audio.
> It was a nightmare to add proper support for it! (we got alot negative
> feedback from customers regarding audio - it now works but other
> issues are still remaining).
> 
> 4. I use Skype-out with my notebook, finally I thought everything is
> working BUT .. no. People I called complained about the audio quality.
> 5. simply running apt-get remove pulseaudio -- hey it solved all the
> issues I had? How comes? Alsa is working fine?

I've said this to you many times before, but here is the situation:

1. PA is an invasive technology. By it's nature a *lot* of things change
and there are obviously areas where bugs will be introduced. This
situation is needed from time to time and yes it's a pain, but such is
life. More people using it means more bug reports and faster fixes.
2. PA is using a very new part of the ALSA API that not all drivers have
proper support for. This area has been overhauled significantly in the
last year or so and many fixes and implementation of the necessary logic
has followed. Comparing this new part of ALSA to the old ALSA is
invalid. PA now gets the defacto blame for the bugs in this code,
because "aptget remove pulseaudio" makes everything "work", but that's
not to say the problem is always at PA's door.
3. ALSA is very flexible but it has several quirks. The API is very
complex and due to the organic nature of it's evolution. Some time ago
Lennart wrote the guide to audio APIs[1] which (I believe) coined the
phrase "Safe ALSA Subset" which basically spelled out which parts of the
ALSA API app developers should limit themselves to in order to create
portable code. This guide doesn't just apply to PA, but it certainly
affects PA hardest as it's probably the most prolific use case for the
ioplug system in ALSA in which the ALSA->Pulse compatibility layer relies.

So add the above problems together and add in the obvious possibility of
bugs in PA itself, sensitivity to kernel options regarding scheduling
and latency and you get more or less the perfect storm for potential bugs.

Add to this some pretty poor adoption strategies at the distro rollout
end and you've got yourself a hotpot of issues showing up.

It's certainly not an ideal situation, but it's totally unfair to level
all the problems squarely at PA's door. Maybe rollout could have been
handled better, maybe distros switched too early, maybe. But as with
quite literally *every* project, users will complain that it's "too
early" etc. etc. There is a massive expectation that users have that
things should be tested to the n'th degree and viciously QA'ed before
release - this does happen but it's certainly not on the same scale as a
commercial product - this is Free software and with Free software we
need wider QA and testing feedback from the general populace in order to
drive the development. So as with all new things (KDE 4, Amarok 2,
PulseAudio, Firefox 3 etc. etc.) you'll get a backlash from users
expecting everything to be hunky dory on day 0. That is an unrealistic
expectation from this type of development IMO.

As anyone involved with Linux audio will testify, we need something with
the featureset that PA offers to take us through to the next level -
ALSA on it's own is not enough (without significant re-engineering).

I have written myself about this in the past several times[2] with
regard to the actual need of a modern, multiuser desktop system.

> So what is the idea behind pulseaudio?

> Also pulseaudio breaks the alsa support (eg. if root wants to access
> audio it does not work root will get permission denied!)

No it doesn't. Even tho' we discussed this until I was ready to explode,
you still don't seem to understand the problem properly.

1. Root login via tty: audio works fine.
2. Root login via X: audio works fine.
3. Root login via su under X with PA running already: works fine (due to
access to the root X11 window for cookie+socket information)

The problem you have is that you want root to have audio at all times. I
agree this is not supported by PA which implements a proper user-based
access policy dictated by consolekit and does not deal with the root
user getting access at all times.

This is something not supported by the PA design. It would need rather a
large rethink to support this, but it's likely not something that is
going to get any focus for the short term - it's a rather niche use case
for typical desktop computing even if it does affect users of e.g. mpd
which is rather popular.

> So how should this be solved now:
> 
> Skype needs to work, the software is good even if it is closed source,
> right now 11 Million people are signed up (according to the list,
> don't know if skype fakes it or not)

I've been working with the Skype dev who is implementing PA support to
try and help get a good implementation.

Skype works pretty good right now. I can make a call have it work on my
internal laptop speakers, fumble about in my bag to find my BT headset,
open it, have PA detects it perfectly, realises there are "phone"
streams active and then moves them over to my headset. It's pretty damn
good right now! This is how VoIP should work!!

Things are not perfect. There are some UI issues to resolve to prevent
unrealistic requests from users, and the AGC will probably not work
perfectly for this release with PA, but I'm sure the next update will
see that working again.

> Personally I do not like pulseaudio, it never worked correctly (an
> example with Ubuntu 9.10: http://sundtek.de/support/pulseaudio.wav ..
> after killing pulseaudio it worked)

Again, saying "after killing pulseaudio it worked" has little to no
merit. The audio paths are completely different, it avoids about four
different layers of potential issues. I'm not saying that there are no
bugs in PA (of course there are), but we need proper metrics and bug
reports to deal with problems, not "it sounds funny" or "it's broke"
rhetoric.

> Comments?

My main comment is that you do not provide any technical arguments at
all. You are just complaining because you hit some problems. Yes, this
is annoying and frustrating, but you cannot simply abandon an
architecture because of some bugs - you have to think about the
components and mechanisms that make up that architecture and why it's
there. I've writen about this in the past[2] so I wont regurgitate this
information here, but if you care to use the points I raise and reasons
I give for why some kind of userspace audio system is essential for a
modern linux desktop and then argue either against my opinion or suggest
an existing alternative or promise to write your own alternative then
this discussion can become exactly that - a proper discussion. Not
actually discussing any of the architecture in an email with this
subject is certainly doomed to end up in the bit bucket.

Col

[1] http://0pointer.de/blog/projects/guide-to-sound-apis.html
[2]
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list