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

[Gene Heskett]

On Monday 21 December 2009, Colin Guthrie wrote:
>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
>
Colin, you make excellent sense, and have demoed a great tolerance for us who 
complain.  A tip of the hat to you sir!

But lets make our side of it a bit clearer if I can.

1) Many of the 'complaints' could be handled by decent documentation.  Where 
is the 'man pulseaudio' that should serve as the grand central station 
dispatcher to point at the other manpages that might answer our individual 
questions?

Oh, , right, I forgot it doesn't exist. (insert suitable sarcasm smiley here)

2) Vital pieces of it are not part of a default install, and we have no clue 
that we need to have such and such until we come here (or some other list 
where such questions are quasi-germane) and complain (in a more or less 
steady stream) and someone will reply "Do you have pavu and pacntrl (or 
whatever its called) installed?"  The answer of course is no, we didn't know 
we needed them.

And once installed, there still aren't any man pages to give us a little help 
if the install doesn't fix it.  So we (at least on fedora) remove the pa 
pluggin for alsa, and we then have _most_ of our audio system back under 
control, kmix is usable etc.

As I have stated before, it appears that on a machine with more than one 
audio system, pa picks a default, and we are silent if that default is not 
functional or even hooked up, which is the case for the video card in this 
machine, which claims to have an intel hdaudio facility but which isn't even 
bonded out to pins on the chipset of an ATI rv610 (HD2400 Pro) video card.

Well, I did install all those 'extras', and nowhere in their menu's was there 
a place to tell pa which of the available audio facilities it was to use for 
all defaults.  I tried to add an entry to /etc/modprobe.d/blacklist that 
would disable the asus onboard and the video card stuff, but after rechecking 
the spelling several times, and several reboots, that didn't work.  So I next 
removed from the kernel build, all references to both the asus onboard and 
video stuffs, leaving only the audigy2 (emu10k1) functional.  That only sorta 
worked for about half the sources, often with low levels and extreme 
distortion.  Questions posted about it got me the std reply, remove the alsa 
pa pluggin.  And with all the dependencies the rest of pa has, its the only 
thing I could remove that didn't take hundreds of other X and kde related 
packages with it. And those dependencies are, IMO, 100% equal to that pile of 
steaming material usually found on the ground behind the male of the bovine 
specie.

So in the end, I removed the pa plugin for alsa, and now 98% of it works, and 
works well.

One old farts story maybe.  But it is the distasteful experiences such as the 
above, that make me very hesitant to take the chance of once again breaking 
the system just to see if the latest, even more fringes and bells equipt pa 
_might_ work.

Coding is kewl, I do it myself on smaller systems, but  where are the man 
pages that should allow us to make it Just Work(TM)?

I think the majority of us are interested.  And contrary to rumors extant all 
over the web, the majority of us _can_ read and follow directions.  We just 
don't have a thing to read yet.

>[1] http://0pointer.de/blog/projects/guide-to-sound-apis.html
>[2]
Off hand, useful only to experienced coders.  Coders who probably already 
know most of it.

>http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-co
>nfidence/
With all due respect Colin, 100% rose colored glasses propaganda.

Nothing in either of those links can teach me how to fix _my_ pa problems.

I truly wish it weren't so.

Thanks for reading.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Kludge, n.:
	An ill-assorted collection of poorly-matching parts, forming a
	distressing whole.
		-- Jackson Granholm, "Datamation"