This document outlines information that soundcard vendors need in
order to be compatible with ALSA and Linux at large. It is targeted
mainly for companies that design and sell soundcard hardware. It may
also be useful to new ALSA developers who desire a background about
information they get from a given soundcard vendor.

ALSA stands for Advanced Linux Sound Architecture.
Its main goal is just what its title says, to create an advanced sound architecture for Linux.
ALSA is committed to being released under the Gnu GPL.
The scope of the project extends from the low level soundcard drivers, all the way up to a high level sequencer.
This document is mainly concerned with what is needed to develop the low level soundcard drivers.

ALSA is the sound driver subsystem of the mainstream Linux kernel. ALSA is fully compatible with OSS/Lite Mixer and PCM
interfaces. ALSA offers better native interfaces that new applications can use.

Good documentation is needed before ALSA developers can write good
drivers. Basically, we need to know everything that anyone else
writing a driver would need to know. Most of the information we need
should be in the data sheets of each chip. We also need to have a
memory map of all the chips, and any additional registers that may not
be included in other data sheets.

It is important that the firmware for a given soundcard is made
available to us. By firmware, we mean code that would be downloaded to
a piece of hardware that is necessary for it to function. i.e. code
running on some DSP chip that is located on the soundcard. This would
not be code that runs on the host system. (Host system is the one
running Linux.) It is important that there are no distribution
restrictions on the firmware. We must be able to freely distribute the
firmware code as part of ALSA. We would like the source code for
firmware. It is not required that it is given to us, but we are
definitely willing to accept it.

We also may need some additional information about how the sound
card works. This varies a lot from card to card. For example, if a
programmable PLL needs to be programmed to a certain frequency before
the card will function, we need to know this. If your company can
appoint a contact person for additional information, that would be
great! Generally, we do not have very many questions. We are used to
developing drivers on our own. We will not be taking up much of that
person's time.

We would also like any example source code that could be given to
us. Obviously this is not as important as the other issues. But
example source code can often be helpful, especially for parts that
are poorly documented.

Unfortunately, ALSA developers generally do not want to sign
non-disclosure agreements, or NDAs. It is possible that a few ALSA
developers could individually sign these types of agreements, but that
would have to be worked out on an individual developer basis. It has
happened in the past. We do not recommend the use of NDAs at all,
because one way or another, they restrict our development effort. It
should be possible to give ALSA developers the information they need
without requiring an NDA. Many companies regularly do this.

Our big problem is with NDAs that restrict the release of our
source code. Since ALSA is released under the Gnu GPL, all of our
source code is made publicly available. Agreeing to an NDA that
requires binary-only distribution of our code conflicts with the Gnu
GPL. Thus we cannot agree at all to NDAs that restrict the release of
our source code. Besides, binary only versions of kernel drivers just
does not work very well in Linux.

Another type of NDA would restrict soundcard documentation to a
small group of people. This type of NDA is at least feasible, but it
still restricts our development effort. The problem is that only those
persons covered under the NDA may be capable of fixing bugs and
providing new features for that card. Often, people from all over the
world send patches to our code. We want all these people to have
access to the documentation. It hurts our project when some people, who
are very capable of sending patches, will not be able to write them in
the first because of lack of documentation.

There are several reasons why your company would want to give us the
information we request. The most important reason is that it will help
your company sell more cards! Many times Linux users ask us which
cards we support. We tell them, and they go buy these
cards. Obviously, the only cards we can support are those we can get
good documentation for.

Also, by making your soundcard documentation public, you really
have contributed something to the Linux development effort. That
should give you a good, warm, fuzzy feeling inside.

There other reasons too. First, other operating systems will have
an easier time supporting your hardware. Second, many developers will
be able to double check our driver, making it very robust. In the end,
this makes your hardware look good. Also, people interested in doing
custom things with your hardware will be able to, giving you another
venue for sales.

With the user base of Linux growing so rapidly, can your company
really afford not to support ALSA and make your soundcard
documentation public? We are not asking for your corporate secrets
here. We are not asking for the Verilog source code for each chip in
your product. We are not asking for schematics, gerber plots, or
anything like that. We just need basic information that enables us to
write a good sound driver.

ALSA does not stop anybody from releasing binary-only drivers. But
ALSA does not support nor encourage these drivers either. The stance
that ALSA takes on binary-only sound card drivers is similar to
Linus's stance on binary-only drivers in the kernel. There is an
article in the Linux Weekly News
about this. There are additional requirements that ALSA places on
binary only drivers beyond Linus's view.

Linus Torvalds, leader of the Linux development effort, has stated
that because binary-only drivers depend so heavily on a given kernel
version, and therefore are so prone to "breaking" when kernel
development proceeds, as it is bound to do, he does not intend to
support nor encourage the use of binary-only loadable drivers.

If Linux developers were to try to maintain compatibility with a given
binary-only driver, it would severely limit the avenues of
development open to Linux. Our goal in Linux development is to
achieve the highest performance, the best stability (in terms of bug
free code), and the most advanced technology possible.

We simply cannot be made subject to the limitations that would be
placed on us by having to maintain compatibility with a third party
binary-only loadable module.

We, the ALSA development team, working as a subset of Linux kernel
developers, agree with Linus Torvalds' reasoning. And this is the very
crux of why we ask you for documentation on your hardware. We truly
want to purchase and use your hardware in our Linux based systems, but
we simply cannot use binary-only drivers; it's just too cumbersome and
frustrating for all involved. Drivers that could be distributed as
source code would eliminate all of those problems.

There is nothing to stop any company from developing a binary only
driver that works with ALSA. But there are several issues and
requirements we want to make clear to anybody attempting to do this.

Binary-only drivers will not be distributed as part of ALSA, even when ALSA becomes part of the mainstream kernel. That means any company releasing binary only drivers will have to find alternative distribution mechanisms. They cannot rely directly on ALSA for this. The main implication of this is ALSA will work "out of the box" with all sound cards, except for unsupported cards.

Users of binary only dirvers must be instructed not use ALSA for technical support whatsoever! These users must be notified with the following notice.

"These drivers are not part of the official ALSA distribution. ALSA will
never support these drivers. DO NOT attempt to contact ALSA for support."

The end user MUST always confirm this notice by downloading, or unpacking the drivers. There must also be some contact listed that is available for technical support. ALSA resources must not be listed anywhere as avenues for support.

Binary-only drivers cannot be based on any ALSA source code. They must be written from scratch. Binary-only drivers that contain ALSA code are infringing on copyright laws.

The developer assumes full responsibility for ensuring the driver works accross new versions of ALSA, different kernels, and different platforms. If we change ALSA, and a binary-only driver cease to work because of it, we will not do anything to fix it.

All our drivers are distributed in source form. The single source
file works with all kernel versions, all platforms, and all ALSA
versions. There is only one source for us to maintain and
support. (Elegant, isn't it?) We really like it that way. Drivers
distributed in binary form may require multiple builds, even though
the source does not need to change. Obviously different binaries are
needed for different platforms. In addition, it is possible that
different binaries are even needed for the same platform depending on
the kernel version, or ALSA version.

This may not be as bad as it seems. Once ALSA reaches version 1.0,
the same binary may work across multiple kernel and ALSA releases. But
we are not making any promises. Again, all of these problems go away
when the driver source is released under GPL to the public.

We do understand that sometimes companies feel compelled to hide
their hardware implementations by not releasing the driver source.
The general Linux user base most likely prefers that any driver is
available for a given piece of hardware rather than no driver. So
please do not let ALSA's stance on binary only drivers deter your
company from releasing one. Since ALSA is open source and is
documented, everything you need to write binary only drivers is
available. We are not out to stop you, but we can not make any
promises that your binary driver will work across all future releases
of ALSA.

ALSA wants to support your soundcard hardware. We have something
really good here that we think should run on all sound cards. It is a
well thought out, open sound architecture that is capable of
supporting the needs of musicians, audiophiles, game players, home and
business users alike. It has easy-to-use APIs. It provides a level of
modularity and flexibility never seen before in a sound
architecture. There are many great minds collaborating on ALSA, and
even though it is currently in the very early stages, so far the
results are outstanding. As a soundcard manufacturer, ask yourself one
question. Do I want to be part of something great?