PulseAudio creator Lennart Poettering
He likes photography and skiing, but the primary concern of Lennart Poettering is advancing the Linux audio experience with PulseAudio, an open source sound server.
PulseAudio’s impressive set of features include per-application volume controls, a modular architecture, support for multiple audio sources and sinks, the ability to discover other computers using PulseAudio on the local network and play sound, as well as change which output device an application plays sound through -- while the application is playing sound.
It's pretty obvious that the complaints and criticisms about PulseAudio you can hear in some forums are not really shared by the vast majority of technical people
Previously, the Open Source Identity series has featured interviews with Ruby on Rails creator David Heinemeier Hansson, Linux’s Linus Torvalds, Jan Schneider of Horde, Mark Spencer of Asterisk fame, Spine CMS creator Hendrick van Belleghem, and Free Telephony Project founder David Rowe. This time we catch up with Lennart immediately after this year’s Linux Plumber’s Conference to find out the latest PulseAudio (PA) developments.
What are some of recent developments with PulseAudio? How are you responding to criticism over the role of PulseAudio?
I am not too concerned about most of the criticism and flames that erupt from time to time on various channels. All the big Linux distributions have adopted PulseAudio and it is an integral part of both the Palm Pre and the Nokia N900 devices, as well as Intel's Moblin.
That basically means that PulseAudio has been adopted by about everyone who could adopt it. There is not really anyone who doesn't do PulseAudio anymore.
Acknowledging that simple fact makes it pretty obvious that the complaints and criticisms about PulseAudio you can hear in some forums are not really shared by the vast majority of the technical people -- quite the contrary.
So, where do they come from? Usually from users who are encountering problems when running PA in conjunction with particular hardware drivers, or higher-level software.
While PA itself is certainly not bug-free (no software is) the majority of issues were triggered by misbehaving drivers or by misbehaving applications.
More specifically some applications were still using audio APIs [OSS] that are almost impossible to virtualize. And also PulseAudio makes use of a lot of driver functionality that was previously unused and hence little tested.
In fact, for quite a few parts of the lower level ALSA APIs PulseAudio is the first user of all. And of course, it cannot be a surprise that we expose bugs that were previously unknown in the drivers this way.
It's not my intention to shift the blame around though. PA and the other layers of our stack should not be viewed as independent parts. If PA uses a new or previously unused feature of the drivers then we need to fix the drivers at the same time.
If we make PA expect more correct behaviour from the apps, or that applications stop making particular assumptions about the audio stack, we need to fix the applications at the same time.
And thanks to the fact that this is all free software doing that is actually possible. And we tried to do that in the past and are getting better at it.
One should never forget what we are doing here. We took an audio system that followed the low-level design that was current in the early '90s and brought it in one big step to what is current today.
We inserted an entire new layer into our stack right in the middle, so that we can catch up with the more advanced audio stack that Mac OS X or Windows provide right now. Doing something like this, of course, will trigger problems at many places. Criticism hence must be expected.
Also, I get a lot of personal e-mails with feedback on PulseAudio and, despite what some people might think, the positive comments actually outnumber the negative comments by far.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.