Linux Audio Developers and Users (LAD)

The Linux Audio Developers and Users community, widely known as LAD, is the long-running technical backbone of open source audio on Linux. This page is the editorial hub for everything LAD-related on Linux DJ: how to subscribe, where to find resources on latency tuning and audio APIs, how to navigate the mailing list notes and event history, and where the important conversations actually happened over two decades of kernel patches, driver work, and real-time scheduling debates. Below I cover who LAD serves, how the list and its surrounding resources are organized here, a compact timeline of how the community evolved, and direct paths into the specific reference pages, FAQ, event listings, and member directories you need.

What LAD Actually Is

LAD is not a product, a company, or a formal standards body. It is a community of practice. In practical terms, it started as a mailing list where kernel developers, audio application authors, plugin writers, and working musicians could discuss the real problems of making sound work reliably on Linux. Over time it became the de facto coordination point for projects like JACK, ALSA userspace tooling, LADSPA and LV2 plugin standards, and the early conversations that eventually shaped PipeWire's design assumptions.

The list itself carried a density of technical discussion you rarely find in modern forums. Thread subjects ranged from interrupt coalescing behavior on specific chipsets, to the politics of getting real-time scheduling into mainline kernels, to surprisingly heated debates about whether 32-bit float or 24-bit integer was the correct internal format for a professional audio bus. These were not theoretical arguments. They were fought by people shipping code and running sessions.

If you have spent time on linux-audio-dev or linux-audio-user mailing lists, you have touched LAD territory. If you have filed a bug against JACK's transport sync, asked why your Firewire interface drops frames after 40 minutes, or wondered why rtprio limits in PAM do not behave the way the documentation suggests, you have engaged with problems LAD participants were discussing years before they reached mainstream distribution bug trackers.

Who This Page Is For

This hub is for three overlapping groups:

• Working audio practitioners on Linux who want practical answers about latency, driver configuration, plugin hosting, and real-time scheduling without wading through a decade of unindexed mailing list threads.
• Developers building audio software or kernel modules who need reference material on ALSA APIs, JACK internals, PipeWire integration patterns, and the design rationale behind decisions that shape the stack today.
• Newcomers who found Linux audio confusing and want a curated entry point rather than a raw dump of every message ever posted. The FAQ and subscription guides here are specifically designed to reduce the time between "I want to try this" and "I understand what is happening."

If you are looking for audio quality tuning that goes beyond community discussion into specific ALSA, JACK, and PipeWire configuration work, the Linux Audio Quality guide covers that in detail.

How This Site Organizes LAD Material

The LAD section here is not a mirror of the mailing lists. It is an editorially organized set of reference pages, each designed to answer a specific kind of question quickly. Here is the map:

Subscription and Participation

The subscription guide covers how the LAD mailing lists work, what to expect when you join, posting etiquette, and the practical mechanics of subscribing and managing your digest preferences. If you have never participated in a technical mailing list before, start here. The conventions are different from forums, and understanding them saves you from the kind of first post that gets ignored.

Frequently Asked Questions

The LAD FAQ distills the most commonly repeated questions from years of list traffic into direct answers. Topics include real-time kernel requirements, which sound server to choose, how to diagnose XRUNs, why certain interfaces work better than others, and the perennial question of whether PulseAudio (and now PipeWire) can replace JACK for serious work. The answers are opinionated where the evidence supports it and honest where genuine trade-offs remain.

Technical Resources

The resource pages are organized by domain rather than alphabetically, because that is how people actually look things up:

• General resources - the starting index for tools, documentation pointers, and community reference material across the Linux audio stack.
• Latency resources - everything related to real-time scheduling, kernel tuning, buffer behavior, interrupt handling, and the measurement tools you need to actually quantify latency rather than guess at it.
• API resources - developer-facing documentation covering ALSA, JACK, PipeWire, LADSPA, LV2, and related programming interfaces. If you are writing audio software on Linux, this is the reference page.
• Community links - curated pointers to active projects, distribution-specific audio guides, and ongoing development efforts within the Linux audio ecosystem.
• Mailing list resources - details on the various linux-audio mailing lists, their scope, their conventions, and how they relate to each other. Not every list covers every topic, and knowing which one to search or subscribe to saves significant time.
• Member directory - a reference for notable contributors, project maintainers, and people whose names you will encounter repeatedly in list discussions and commit logs across major Linux audio projects.

Events

The LAD events page documents conferences, developer summits, and community gatherings that shaped Linux audio over the years. The Linux Audio Conference (LAC) series in particular produced important technical presentations and papers. For a broader view of Linux audio events beyond the LAD-specific ones, see the main events section.

Discussion Notes and User Pages

The discussion notes page provides structured access to significant threads and technical exchanges from the mailing lists, organized by topic rather than chronology. The user pages section collects community-contributed material, setup notes, and configuration examples that members shared over the years.

How LAD Topics Evolved: A Compact Timeline

The Linux audio community did not arrive at its current shape overnight. Understanding the sequence helps make sense of why certain tools exist, why some debates keep resurfacing, and why the stack looks the way it does today.

What the timeline shows is a steady arc from "can we make sound work at all" through "can we make it work professionally" to "can we make it work for everyone without sacrificing the professional path." Each period generated its own body of list discussion, its own set of tools and patches, and its own community dynamics. The resource pages linked above are organized with this evolution in mind, so you can find material relevant to your specific era of hardware and software without sorting through everything chronologically.

The Shape of the Discussion

One thing that surprises people encountering LAD material for the first time is the directness. Mailing list culture, especially in technical Linux communities, rewards precision and penalizes vagueness. A question like "my audio is broken, help" would typically get no response. A question like "XRUN count increases linearly with CPU load on a Focusrite 2i2 gen3 at 64 samples, kernel 6.1, PipeWire 0.3.65, governor set to performance, here is my pw-top output" would get three informed replies within hours.

This is not hostility. It is efficiency. The people answering questions on these lists are often the same people writing the drivers, maintaining the build systems, and debugging race conditions at 3 AM. They are generous with their knowledge but allergic to incomplete problem descriptions. The FAQ and subscription guide both address how to participate effectively, including how to format bug reports, what information to include, and what to search for before posting.

Connecting the Pieces

The LAD section does not exist in isolation. It connects to other parts of this site where the topics overlap:

• The audio quality guide takes the theoretical knowledge discussed on the lists and translates it into specific ALSA, JACK, and PipeWire configuration steps with measured results.
• The latency resources page collects the kernel tuning and scheduling references that were debated extensively on linux-audio-dev over many years.
• The API resources page serves developers who need the programming references that underpin the tools discussed in community threads.
• The events section documents conferences where many of these discussions moved from mailing lists to in-person presentations and collaborative coding sessions.

Every resource page, FAQ entry, and event listing in the LAD section is written with the same approach used across this site: practical, specific, and grounded in the experience of actually running Linux audio systems in production. No filler. No padding. If a page does not save you time or teach you something concrete, it does not belong here.

Getting Started

If you are new to all of this, the best entry point depends on what you need right now:

• Want to understand the basics? Start with the FAQ. It covers the questions everyone asks first.
• Want to join the conversation? The subscription guide walks you through signing up and participating effectively.
• Need to fix a latency problem now? Go directly to the latency resources. They are organized by symptom and system layer.
• Building audio software? The API resources and community links are your starting points.
• Curious about community history? The events page and the timeline above give you the arc.

Whatever path you take, you are engaging with one of the longest-running and most technically substantive open source audio communities in existence. The tools are better than they have ever been. The documentation is catching up. And the people doing the work are still here, still shipping code, and still willing to help if you meet them halfway with a clear question and a willingness to measure before you assume.