Testing Request for KDE+PulseAudio users

[Colin Guthrie]

'Twas brillig, and Mark Kretschmann at 06/10/09 12:35 did gyre and gimble:
> I have to agree with Allan here, without meaning to be insulting to
> PulseAudio's developers.
> 
> From my point of view, PulseAudio is causing more problems than it
> solves. The issues with ALSA should be solved in ALSA itself. Or we
> could investigate using OSS 4.

Well this is exactly what I feared this thread would turn into :( But in 
the interests of trying to qualm any (IMO) unjust opinions of PA 
spreading, I'll try and write a rebuttal! It's quite long, but I hope 
the people who asked the question will read it all as I think the points 
I make are valid.


I come across this kind of comment/question quite a lot and a while back 
wrote up my thoughts on the matter here:
http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/

But in the interests of simplicity I'll try and summarise here too:

Phonon is a fine system. I'm do not have anything against it or 
particularly for it. As far as I see it, it's and API for use in KDE. 
Great. That said, it's certainly not the place to fix "sound on linux". 
It requires that applications use it's API to work properly regarding 
categories and device preferences etc. This must be approximately 0.1% 
of sound producing applications on linux (if it's even that high).

I quite often get people asking me for support wondering why when they 
run Audacious or RhythmBox on KDE (without pulseaudio) that their 
preferred sound devices are not used? I have to explain that the setting 
and priority lists define in KDE are only for KDE apps, and other apps 
must be configured separately. They often don't understand (or want to 
understand) which apps are KDE ones and which ones are not. They just 
want their sound to work as they have (thought they have) configured it!

I don't think it's overly controversial to suggest that anything that 
goes into phonon specifically will not solve the underlying problems for 
non-KDE applications, which are frequently run within a KDE context and 
on the console, under gnome etc. etc.

It is my goal to make the preferences specified in KDE regarding sound 
priority work for *all* applications. This is the reason I wrote the 
patches in this thread.


So, considering the above, there has to be something governing sound at 
a lower level.

Now addressing some specific points:

More and more audio device *are* network based. Apple Airport Express 
devices are pretty popular these days. I have two bluetooth headsets and 
my hifi system also support bluetooth connections. My Playstation 3 
supports uPNP media renderers. So lots of things relating to network 
Audio are popping up (which is nothing to do with pulse->pulse network 
connections which is arguably a toy, even if I do personally use it a 
lot!). I don't think these should be ignored. PulseAudio supports all of 
these devices right now (although I've not had time to try the uPNP 
stuff on my PS3 specifically so don't quote me on that!)


In addition, rights access and management is a big issue. Today any 
modern linux desktop uses console kit to keep track of user sessions. 
When you switch from one user to another, console-kit ensures that the 
currently "active" user session is set to inactive, and it triggers udev 
callouts to remove the currently active users ACL on the /dev/snd/* 
nodes. (I seriously hope no one adds their user to the "audio" group 
these days!). This allows a new user to log in and get access to the 
sound hardware because they are now the "active" user. Switching between 
the two sessions triggers these ACL rewrites. Something has to manage 
this in applications so that they don't just bail out with EPERM errors. 
The sound has to go to /dev/null automatically without the application 
being aware of what is going on. Perhaps it can cork/uncork applications 
that listen for such signals so that music is paused etc. This is 
something that cannot be done without some kind of userspace daemon 
handling things.


Then on to power consumption. What most people quite often fail to 
realise is that Latency is Good. If you can pump 20 seconds worth of 
audio into a buffer and then switch off until you're woken up 19.5 
seconds later then this is great for power consumption. You need to 
disable hardware interrupts and use kernel level timing constructs to 
deal with this, and automatically reduce your wakeup time on the event 
of an underrun to reduce the likelihood of a future underrun occurring. 
You also have to have accurate timing information reported such that a/v 
applications can handle things like lipsyncing etc. (and remember that 
hoping for a low latency audio output is no way to get lipsync! If the 
audio output device is network based (bluetooth headphones etc.) the 
time delay from audio pumped into the buffer to when it's heard can be 
much increased and this needs to be handled gracefully!). On embedded 
systems and laptops, power consumption is very important which is one of 
the reasons why there is so much interest in PA from the likes of Intel 
and Nokia just now. Now, I admit that this mechanism did uncover many 
problems in the alsa driver layer. These problems have largely been 
resolved now, but many people seem to project these issues as pulseaudio 
problems which is unfair. For more information on latency see 
http://pulseaudio.org/wiki/LatencyControl  and for more information 
about the timer based scheduling see here 
http://0pointer.de/blog/projects/pulse-glitch-free.html I strongly 
recommend you read both.


Then of course there is the mixer. Everyone knows the ALSA mixer 
controls are insane. They make no sense to almost everyone and vary 
wildly from hardware to hardware. Pulseaudio does a very good job at 
rationalising this and while it's impossible to get this 100% right, 
it's coping admirably just now, while pushing for sanity upstream in 
ALSA. PulseAudio development really has pushed the ALSA development, 
both in terms of the kernel-level drivers (see previous paragraph) and 
the userspace API.


Then there is the whole concept of thin-clients. This is where native PA 
netowrk support goes beyond the "toy" label I gave it above. In this 
scenario it's rather important. Right now if I ssh to another machine on 
my network and run Amarok there, I hear the sound on my local speakers. 
This works by piggy backing connection and athentication information 
into the X11 root window which is SSH knows how to forward. Arguably 
this is not ideal as it needs a direct network return path and open 
ports etc. The correct solution is to abstract the X11 forwarding foo in 
ssh and implement a PA forwarding option too. This will come in time. 
I've written a bit about how this kind of thing works here: 
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/



Now the comments that opined pulseaudio was designed without KDE in mind 
are very true. It was designed to fit in with nothing in particular. 
Sure, it's had some love from Gnome with the bundled UI tools written in 
GTK (but these were just examples anyway - it was expected that 
integrated tools for DEs would be written which has happened for Gnome 
now, but not yet for KDE). But the core of PulseAudio does not have any 
gtk or glib dependencies (yes, there is a gconf module which acts as 
glorified module loader, but it's optional and I'm already working on 
deprecating it anyway with module-loader). Considering Qt has a glib 
dependence for the mainloop, that's not bad going!

The routing system in PA's core is modular and the current 
implementations do not follow the same routing policy as KDE. Does this 
mean it's not designed with KDE in mind? I don't think so, I just think 
it means no one has written the module that implements the KDE routing 
policy yet... But I've now done exactly that! In addition, pulseaudio 
interprets the .desktop file of any application playing sound and is 
often able to work out the category (aka "role" in PA) correctly. This 
means that the category device priority configured in KDE will work for 
other non-phonon apps without even trying!


As for those that say "this should be done in alsa", would you feel any 
better if PA was called alsad? The system needs a userspace daemon for 
all the reasons above (handling the permissions, glitch-free governance 
and latency aggregation over all streams). So if it were "done in alsa" 
would it be much different other than in name? I doubt it.


As for those who have had poor experience with PA, I have to say that a 
lot of this criticism is due in no small part to the distros. I package 
for Mandriva and I care about user experience and made sure that when we 
adopted PA several release ago that I configured and setup the vast 
majority of audio applications to work OOTB with PA just fine. I also 
ensured that it is very easy to turn PA off if you don't want it. This 
seems to be something I've seen people complain about recently: "I have 
to use PA because my distro breaks if I remove it!". Well, you shouldn't 
remove it (due to linked library problems) but there is absolutely no 
reason why you cannot disable it. If you can't, then this is a distro 
problem pure and simple. Complain to your distro or switch to one that 
does it properly. The power is yours.

Now I don't like to get involved distro wars, but Ubuntu has had a very 
poor track record with PA. They introduced it in an LTS release with 
very little though or due care and attention. This has harmed opinion of 
PA considerably. Ubuntu has gotten much better since then, the people 
involved are engaging with us upstream and a really good people to work 
with, but first impressions are hard to shake. I hope all the Ubuntu 
users and especially the Kubuntu users (I don't think phonon or kde 
runtime was patched in Kubuntu like I did to make it work sensibly, 
albeit with a crippled UI if (and only if!) the user is using PA, but 
correct me if I'm wrong) who formed their opinions of PA back then will 
give PA a second chance on a well integrated setup. As stated before, 
the PA output layer in Xine is also far from ideal. So please try a 
different backend for the purposes of evaluating PA properly and don't 
shoot the messenger! (slightly contrived cliché usage there :p). 
Hopefully I or someone else will find time to improve the Xine support, 
or one of the other engines will ultimately replace it (I live in hope!)



I hope I've given a comprehensive overview of why I personally think 
that PulseAudio is the right horse to back just now. I hope the people 
who have asked the questions will do me the service of reading it, and 
the linked material, thoroughly as it didn't take 5 minutes to write!


> This here is a bit off-topic, as we already have PulseAudio right now
> in many distros, and we need to fix Phonon to make it work properly
> with it. Still, the points Allan raised are valid and interesting.

Indeed and I hope I've addressed Allan's points in the above.

Col

-- 

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/]