Linux Audio Mailing Lists Reference

The Linux audio mailing lists are the primary communication channels for the community that builds and uses professional audio tools on Linux. Unlike forums or chat platforms where messages disappear into endless scroll, mailing lists produce permanent, searchable, quotable records of technical discussion. This matters because the decisions and debugging sessions preserved in these archives have shaped the audio stack you use today. In this reference I cover the purpose and scope of each Linux audio mailing list, how to decide which list is right for your question, detailed subscription instructions, and the etiquette conventions that will get your messages read and answered by people who have been contributing for years. For the broader context of how these lists fit into the community, see the LAD community hub.

The Linux Audio Mailing Lists

There are three principal mailing lists in the Linux audio ecosystem, each serving a distinct purpose. Understanding the boundaries between them is the first step toward using them effectively.

The Linux Audio Developers (LAD) list is where the core technical work happens. This list carries discussion about kernel audio subsystems, driver development, sound server internals, plugin API design, and the deep architectural questions that shape how audio works on Linux. If you are writing code that interacts with ALSA, JACK, or PipeWire at the API level, or if you are working on real-time scheduling, interrupt handling, or audio driver development, LAD is the appropriate venue. The signal-to-noise ratio is high because participants expect messages to contain technical substance.

The Linux Audio Users (LAU) list is for people who use Linux audio tools in practice: recording engineers, musicians, podcasters, sound designers, and anyone running audio workloads on Linux who needs help with configuration, workflow, hardware compatibility, or application-level issues. LAU is where you ask about choosing an audio interface, configuring JACK for live performance, getting a specific DAW working on your distribution, or troubleshooting latency problems that are not caused by kernel-level bugs.

The Linux Audio Announce (LAA) list is a low-traffic, moderated list for announcements only. New software releases, major version updates, event notices, and project milestones appear here. LAA is not for discussion. It is a broadcast channel that keeps the community informed about what is shipping, what is changing, and what events are upcoming. If you want to stay current without following high-volume technical discussion, LAA is the list to subscribe to.

Which List Should You Use

The most common mistake new participants make is posting a user question to the developer list or sending a technical RFC to the user list. Neither is catastrophic, but both reduce the chances of getting a useful response.

Here is the practical test: if your question involves writing or modifying code that operates below the application level, it belongs on LAD. If your question involves configuring, using, or choosing between existing tools, it belongs on LAU. If you are announcing a release or event, it belongs on LAA.

Ambiguous cases exist. A question about why JACK's transport sync does not work might be a user configuration issue or it might expose a bug in the transport implementation. In those cases, start on LAU. If the discussion reveals a code-level issue, the thread will naturally migrate or someone will suggest moving to LAD. Starting on the user list is almost never wrong when you are not sure, because the people who monitor LAU also read LAD and will redirect if appropriate.

Cross-posting to multiple lists simultaneously is strongly discouraged. It fragments discussion and annoys people who subscribe to more than one list, which is most of the active contributors.

How to Subscribe

Each list has its own subscription page with specific instructions. The subscription overview provides direct access to all list subscription options from a single page. The process is straightforward: you provide your email address, choose whether you want individual messages or a digest, and confirm via the link sent to your address.

Digest mode sends you a single message containing all posts from the day, bundled together. This is useful for low-priority monitoring but makes it difficult to participate in active threads because your replies arrive late relative to the conversation. If you intend to participate rather than just read, subscribe in individual message mode and use your email client's filtering to keep things manageable.

Some people subscribe to all three lists. Some subscribe only to LAA to stay informed and join LAU or LAD only when they have an active need. There is no obligation to participate once you subscribe. Lurking is entirely acceptable and is how most people learn the culture and technical conventions before their first post.

Message Etiquette and Posting Guidelines

Mailing list etiquette is not arbitrary politeness. It is a set of conventions that evolved because they make technical communication more effective across large groups of people with different backgrounds, time zones, and levels of expertise.

Write clear subject lines that describe the actual topic. "Help needed" tells nobody anything. "XRUN every 30 seconds with USB interface on kernel 6.8, JACK at 128 samples" tells everyone exactly what the thread is about and lets people with relevant experience find it.

When replying, quote the relevant part of the message you are responding to and write your response below the quote. This is called inline replying or interleaved quoting. It makes threads readable in archives because each response is connected to the specific point it addresses. Top-posting, where you write your entire reply above the quoted message, is discouraged on technical lists because it destroys the logical flow of a multi-point discussion.

Send messages in plain text, not HTML. Many list subscribers use text-based email clients, and HTML messages can render poorly or trigger spam filters. Keep attachments minimal. If you need to share a log file, paste the relevant portion inline. If the file is large, host it elsewhere and link to it.

Be specific about your environment when asking for help. Include your distribution, kernel version, audio server and version, interface model, and the exact error messages or symptoms you are seeing. Vague descriptions get vague answers. Specific descriptions get specific solutions.

Getting Value from List Archives

The mailing list archives represent years of accumulated technical discussion. Before posting a question, search the archives. Your problem has very likely been discussed before, often in depth and with working solutions. A search that includes specific error messages, hardware identifiers, or API function names will usually turn up relevant threads.

When you find an old thread that partially answers your question, reference it in your new message. This shows that you have done your research and helps responders understand what you have already tried. It also avoids the frustration of receiving a reply that simply links to the thread you already found.

The archives are also useful for understanding design rationale. If you want to know why JACK uses a callback model instead of a polling model, or why ALSA's hw plugin behaves differently from the plughw wrapper, the original discussion threads contain the reasoning from the people who made those decisions. That context is often more valuable than the documentation that was written after the fact.