Linux audio layers

Lennart Poettering did a pretty good job of going through the various sound APIs on Linux, he even made a diagram. It shows just how varied and complex the soundscape on Linux is.

Unfortunately for his readers, Lennart started riffing in places when he probably should have stuck to the topics he's familiar with. Given that it's me talking here, you can probably guess what the topics included ... yep, Phonon and KNotify.

For Phonon, Lennart said, "Use GStreamer! (Unless your focus is only KDE in which cases Phonon might be an alternative.)" Lennart works with GStreamer, so he will naturally lean towards it, but this statement is incorrect on many levels.

Phonon has only a Qt dependency, so if you are using Qt it's an option; KDE doesn't come into play in that decision. Many of our KDE4 libraries are like that these days actually. Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer.

But what if you only care about Linux? Phonon integrates well with the rest of your Qt code, makes it far simpler to use the underlying engine, and will happily backend onto GStreamer where it exists. But it also allows the user, system administrator or system integrator decide to use something else besides GStreamer. Or, should GStreamer fall out of favour in the future on Linux, you won't have to rewrite your code.

For event notifications, Lennart said, "Use libcanberra, install your sound files according to the XDG Sound Theming/Naming Specifications! (Unless your focus is only KDE in which case KNotify might be an alternative although it has a different focus.)"

This is the classic "event notifications are about sound" mistake. KNotify is a generic notifications framework that lets you create notifications, in the abstract sense, and then let the framework sort out whether they should be played as sounds, logged to files, etc. Sound is just one aspect of notifications, and providing a centralized mechanism to manage notifications is a (excuse the pun) sound design.

Note also how Lennart used the phrase "Unless your focus is only KDE" twice. What does that actually mean? Honestly: nothing meaningful, though bordering on FUD. That phrase might literally mean (and I'm being gracious here) "If you are use KDE libraries to develop your application." (Yes, it's for Qt-only apps too, as we already know) But what many will probably read it as is this: "If you intend your application to be run only in a KDE desktop ..." That's just wrong ... those frameworks are for use with applications that use Qt and/or KDE libraries. No more, no less and nothing about what one's focus is.

This does bring us back to that blog entry from a few days back about clarifying the KDE brand: in this case it would've made Lennart's characterization of Phonon and Knotify less ambiguous (even if still inaccurate).

Lennart does point out a couple of shortcomings of KNotify: "However it does not support the XDG Sound Theming/Naming Specifications at this point, and also doesn't support caching or passing of event meta-data to an underlying sound system." The sound theme spec thing is a bit lame because it's a brand new spec (GNOME only recently picked it up in their release that was made today) and in typical xdg spec fashion is essentially documentation of one implementation. Others will likely follow, so give it time. The caching bit really has more to do with the sound subsystem, and passing of meta data down into the media layer isn't done either. So I do give him some points there; places we can improve KNotify.

Lennart later says, "Phonon and KNotify should only be used in KDE/Qt applications and only for high-level media playback, resp. simple audio notifications." This makes them sound like toys, and while I won't say that Phonon is what you'd want for a high end pro-audio engineering tool, if you look at apps like Amarok2 its pretty obvious that these libraries are rather above the "toy" status.

So when do you want to use Phonon? When you aren't doing high end pro-audio stuff and need to play audio or video (capture will be there soon as well, I see code in the experimental/ folder already) and you want it to work today and tomorrow on Linux, BSD, Solaris, Windows and Mac using the native facilities. Phonon alone may be reason enough to use Qt in your application, in fact, if only just for multimedia features in your application.

When do you want to use KNotify? When you are writing code that uses the KDE libraries and you want to notify the user of something.

To Lennart: you know a lot about audio on Linux. Thanks for your contributions to FOSS and those explanations on your blog of the various audio bits and knobbles in Linuxland. But do everyone a favor and stick to the parts you actually know: you'll look smarter when someone like me doesn't come along and correct you (so you win) and others won't be misled in a blind-leading-the-blind scenario (so your community wins). If you do want to write about Phonon or other Qt/KDE technologies on your blog, I'd be happy to field questions for you as part of your due diligence research.