You mentioned “it could be that the ALSA drivers for your h/w are not giving accurate timing information to PA”. Perhaps in a separate article you could explain the details of why this raises CPU. Especially with respect to determining if our devices are susceptible, how to fix them, and if any workarounds – say in daemon.pa – could be applied.

Also do you happen to know if the “USB SounBlaster mp3+” devices (usb-041e_USB_Audio-00-MP3) have this problem?

stream restore
Just for clarification, when moving the stream via pavucontrol the changes take place automatically because “the stream restore database is written by some PA client [pavucontrol] which requests the “apply_immediately” flag set.

As for “I don’t want an override anymore”, I agree. Wouldn’t it make sense, if moving a stream to a default device, simply to remove the override?

I really like you proposal and feel that it is more “natural”

What I can tell you is that on my hardware (a 4 year old Intel C2D 64-bit with HDA h/w) the CPU is never more than 2% from what I can tell, with the typical case being 0%, sometimes creeping towards 1%, so I suspect that your higher CPU usage is indicative of something specific rather than some endemic. Find the problematic part and fix it. That is the right way to work with Open Source, not saying “this sucks because it doesn’t work for me right now”, but saying, “OK this is neat but this bit isn’t idea, what can I do to make it better”. If you don’t like it, fine, don’t use it, but if you don’t want to play the game, don’t be surprised if you don’t get much respect from the players when shouting from the sidelines.

With regards to Phonon, I’m sure you’re right that there are more applications than that overall, but I did say “mainstream” usage. Maybe my definition of “mainstream” is a bit harsh, but regardless of the numbers I don’t think there is any disagreement that Phonon covers a tiny minority of sound producing applications on Linux. That is/was the crux of my point.

The fact that you mention phonon vs. pulseaudio is really quite funny. I know both code bases pretty well (look for me in the commits of both) and they are so completely different and target such completely different areas of the audio stack that to compare them is really quite ludicrous which is why I never do! Also while I agree it is a Qt technology, there has also been very little by way of integration work done by Qt people on this. I’ve personally worked rather hard to get good integration with PA and this is done in the KDE version of libphonon. It’s not been taken on by the Qt version yet despite it being available for 6+ months. So it can’t really be called a Qt- technology if all the KDE distros out there basically reply on a KDE fork of phonon. In short, it’s a bit of a mess. It’s fine if you know the rules and where to get package xyz from, but for a general user it’s pretty tricky. I suspect the lack of impetus from Qt on Phonon is that they are already planning the QtMultimedia stuff which will ultimately replace it. With the join up of Maemo and Moblin announced recently I hope that there will be more direct engagement with PulseAudio from Qt directly. Intel is alreay committed to PA on their embedded platforms and this tie-up will hopefully help cement this and provide better Qt support.

Back to your point about alsa being enough on it’s own, I strongly disagree. I thoroughly believe that some form of userspace component is needed to drive desktop audio. From dealing with multi-user and multi-seat issues to dealing with sound from remote X11 applications; from interfacing with bluetooth headphones, amplifiers and headsets to hot-moves of streams; from dealing with device hotplug in a sane way to powersavings from the timer-based model, there are numerous things that are simply not possible with alsa on it’s own and are enabled by PulseAudio.

This blog post is not about discussing that and, as I asked in an earlier comment, I’d like to keep the posts on topic. If you want to talk more about alsa vs. PA then please comment on my earlier article that is much more relevant and contains much more detailed reasoning: http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/

But lets not make this a phonon vs pulseaudio. The question was why use pulseaudio on top of Alsa while Alsa alone works just fine.
Your answer is that it then works for apps like ogg123 too, and thats a sane answer.
But that doesn’t actually answer my question of why not stick to Alsa. What does pulseaudio bring that Alsa doesn’t.
Again, the PA may look nice on the drawingboard (well, your blog puts some doubts there too) but in real life it doesn’t seem to actually add any benefits. Just headaces.

(Of course you could still include the database file for module-device-manager in your /etc/skel if you really wanted a custom default, but it’s probably not worth it!)

I have a little question about module-device-manager. Is there any way to set the priority of each device in the startup script, or in a system wide configuration? Maybe I missed something, but I looked for it a few months ago when I installed Mandriva 2010.0 and found nothing.

This is my scenario, using Mandriva 2010.0 and KDE: I have two sinks, one for the soundcard in the motherboard, and another for the HDMI output in my graphic card. The highest priority device should be the soundcard. However, when I create a new user account and check the device list in Phonon settings GUI I see that the HDMI output is at the top. I have to explicitly move the soundcard device over the HDMI device to get sound.

Of course I don’t create users too often and doing that initial configuration isn’t a big deal, but when using xguest session (which uses a fresh user account every time it is started) it becomes a bit annoying. So, can the priority for each device be set in somewhere like /etc/pulse/default.pa? Thanks for the information.