ZKM Karlsruhe 2004 - Linux Audio Meeting

The 2004 Linux audio meeting at ZKM Karlsruhe was the second in what became a series of annual gatherings for the Linux audio developer community. It was more structured than the exploratory 2003 gathering: sessions were organized around specific technical topics, participants prepared presentations with slide decks, and the documentation produced was more complete. Slide materials from the meeting are preserved at the 2004 slides directory. This page covers the technical context, the session topics, and what the 2004 meeting contributed to the broader arc of Linux audio development. For the event index, see the LAD events page, and for the top-level site events hub, see events.

What Changed Between 2003 and 2004

A year of active development separated the two ZKM meetings, and the difference was visible in the nature of the 2004 discussions. By 2004, the foundational questions that had dominated the 2003 gathering - whether JACK could work reliably, whether real-time scheduling was achievable on standard hardware, whether ALSA provided what applications needed - had moved from open questions to answered questions with known constraints. The community still had significant work ahead, but it had a clearer picture of exactly what needed to be done.

This shift allowed the 2004 meeting to go deeper technically. Rather than establishing that low-latency Linux audio was possible, sessions could focus on specific performance bottlenecks, interoperability problems between tools, and the design of infrastructure that would need to serve a broader user base than the specialist community that had built the initial tools. The move to formal presentations with slide decks reflected this maturity: participants had enough to say that they could structure it in advance.

JACK Transport and Inter-Application Synchronization

JACK transport - the mechanism that allows multiple JACK-connected applications to share a common timeline and move through it synchronously - was an active development topic in 2004. The basic transport API existed, but its practical behavior when multiple applications all had opinions about transport state was not always predictable. Sessions at the 2004 meeting worked through the semantics of transport control, the priority of competing transport requests, and the latency implications of the synchronization mechanism itself.

These discussions had practical consequences for anyone building a Linux audio production environment with multiple applications. A sequencer, an audio editor, and a synthesis engine all need to share transport position if they are going to play back together, and getting that right under load was a more complex problem than it appeared on paper. The 2004 meeting produced both a clearer shared understanding of the problem and some concrete proposals for improving the transport implementation.

Plugin Hosting and the LADSPA Limitations

LADSPA was the established Linux audio plugin standard in 2004, but its limitations were increasingly apparent. The interface was designed for simple signal processing effects and handled that use case well. It did not handle instrument plugins, plugins with MIDI input, plugins that needed to communicate state to a host GUI, or plugins with more complex parameter structures. The community had been working around these limitations for years and was increasingly converging on the view that a more capable standard was necessary.

The 2004 ZKM meeting included sessions on what a successor to LADSPA should look like. The DSSI interface - designed specifically to address LADSPA's lack of support for instrument plugins and MIDI - was discussed in some detail. The longer-term direction that would eventually result in the LV2 standard was also present in these discussions, though LV2 itself was still some time away from a stable specification. The 2004 meeting was part of the working-out process that eventually produced a clearer direction.

Real-Time Scheduling Advances

Real-time preemption in the Linux kernel had made concrete progress between 2003 and 2004. The preemption patchset had become more stable and more widely tested. The 2004 meeting included sessions on the practical state of real-time kernel patches for audio work: which hardware configurations benefited most, what the scheduling latency improvements looked like in measurement, and how to configure a real-time patched kernel for audio production. The slide decks from these sessions are among the more technically detailed materials in the 2004 slides collection.

The real-time scheduling discussion at the 2004 meeting also addressed the interaction between real-time priority and system stability. The fear that giving audio processes real-time priority would make systems unreliable was real and had discouraged deployment. By 2004, enough experience had accumulated to address that fear with data rather than theory, and the session materials reflect that more grounded perspective.

The Slide Decks as a Technical Record

The preserved slide materials from the 2004 ZKM meeting represent a snapshot of the community's technical understanding at a specific moment. They are useful not just as historical record but as reference material for understanding why certain design decisions were made. If you are working on Linux audio software today and want to understand the reasoning behind a particular API choice or architectural constraint, the 2004 slide decks are often more informative than the code comments that resulted from those decisions.

The slides are organized by session in the 2004 slides directory. Each session's materials can be read independently, though the full picture benefits from reading them in the order they were presented. The 2004 meeting was also a bridge to the 2005 ZKM gathering, which built directly on the conclusions reached in Karlsruhe that year. Notes and materials from the 2005 meeting are at the 2005 meeting directory.