Open source audio applications need to learn from listeners

Ask anyone what they use their computer for, and “listening to music” will no doubt be high on the list. Regrettably, there aren’t any Linux applications designed let us do that. Sure, there are applications designed to accomplish data-centric tasks like “play and manage digital audio files” and “control an FM radio tuner card.” These are two very different tasks from a programming standpoint, but interchangeable from the point of view of a user who just wants to listen to music.

Home and car stereos and portable devices all integrate disparate functions. No doubt it is a complex engineering problem for Blaupunkt and Sony, but by focusing on the user’s tasks they create a far better product.

Only in software applications is this distinction made, and consequently we have to use separate apps to play music from different sources. And the problem is by no means limited to FM broadcasts and MP3 playback. How many of the mature open source audio players support basic CD playback? There are a few that support ripping CD audio directly within the app, but cannot play that audio directly off of the disc. Would anyone in their right mind buy a hardware device with that kind of limitation?

Building an application from a data-task perspective locks out the possibility of new features, yet history teaches us that there will constantly be new methods and approaches to delivering audio to listeners. CDs, audio files, streaming radio, DAAP sharing, FM, XM, podcasting — the list goes on. How many new ones will be invented this year?

Nor is the problem strictly a matter of media delivery, in which each new medium has its own characteristic technical challenges.

Consider the interface to the music itself. Back in the WinAmp days, most media players utilized a dynamic playlist interface. Since the introduction of iTunes, most new apps have adopted its “library” browser approach.

But the majority of apps choose just one of these approaches and allow no other. Each approach has its pros and cons, but neither is right for all users, and certainly neither is right for all users all of the time. And unlike media delivery, restricting the way the end user can interface with his or her music collection is symptomatic solely of the developers’ decision.

The underlying cause

There is no malice behind any of these shortcomings in the Linux audio player ecosystem. Rather, I think they are the unintended result of a philosophy that predates Linux, and may in this particular application space do more harm than good.

“Do one thing and do it well” is the first tenet of the Unix philosophy as expressed by Doug McIlroy. Its purpose is not to discourage programmers from building powerful applications, but rather to remind programmers to focus.

But “do one thing and do it well” is a double-edged sword. On the one hand, it focuses our attention on core tasks. On the other, it is a convenient excuse to ignore features, even important ones. And in some cases, it can cement into the design core problems that really ought to be cut out and replaced with no mercy. It is certainly part of the reason we still use separate applications for listening to digital audio files, CDs, DVDs, TV audio, and FM radio.