From alsa-devel-owner@alsa.jcu.cz  Tue Dec 29 21:03:31 1998
Received: from donkeykong.rs.itd.umich.edu (smtp@donkeykong.rs.itd.umich.edu [141.211.63.19])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id VAA26653
	for <alsa-devel@alsa.jcu.cz>; Tue, 29 Dec 1998 21:00:38 +0100
Received: from qix.rs.itd.umich.edu (smtp@qix.rs.itd.umich.edu [141.211.63.87])
        by donkeykong.rs.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA04279
        for <alsa-devel@alsa.jcu.cz>; Tue, 29 Dec 1998 15:00:35 -0500 (EST)
Received: from localhost (cdavid@localhost)
	by qix.rs.itd.umich.edu (8.8.8/5.1-client) with ESMTP id PAA23394
	for <alsa-devel@alsa.jcu.cz>; Tue, 29 Dec 1998 15:00:34 -0500 (EST)
Date: Tue, 29 Dec 1998 15:00:34 -0500 (EST)
From: Chris David <cdavid@umich.edu>
To: alsa-devel@alsa.jcu.cz
Subject: Sound Card Vendor Information
Message-ID: <Pine.SOL.4.05.9812291401300.9167-100000@qix.rs.itd.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


I took it upon myself to write up a description of what ALSA
developers need from sound card vendors. I wanted it to be short, but it
bloated up fast.

I think Jaroslav mentioned that somebody should write something like this
in a previous message, however, I deleted the original message about this
and didn't find it in the archives.

Anyways, this is my first stab at it.  Please let me know if there is
anything that should be added, taken out, or changed.  I think it is
important to make sure that all the main points are covered, whatever
those are.

Also, I really have not done much work on the ALSA project, nor
contributed to Linux projects at all. So it is very possible I missed big
peices of things that should go into this document.  Or that some of the
info I have is false.

Currently, it is in text for easy email xfer, I think the final format
will be HTML, does that sound good?

Thanks,

-Chris

------------Text Document---------------

Title
ALSA Sound card Vendor Information

Abstract

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

Background

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

What we need to write good drivers

ALSA developers need several things to write good drivers.  We need:
   * good documentation
   * necessary firmware
   * a way to get additional information if needed
   * example source code is helpful

Good documentation is needed before ALSA developers can develop 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 for 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 sound card 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.  This
would not be code that runs on the host system. (Host system is the
one running Linux.)  We do not need the the source code for the
firmware.  Firmware in binary form is just fine.  It is important that
there are no distribution restrictions on the firmware.  We must be
able to freely distribute this firmware code as part of ALSA.

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 us to ask questions, and get information
from, that would be great! Generally, we will 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.

Our view of NDAs

Unfortunately, We as 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 sound card 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 fix bugs and provide new features to
that particular driver.  Often, one person who does not regularly
develop a driver will find a bug, and send the original developers a
patch for it.  If that one person does not have access to the sound
card documentation because they are not part of the NDA agreement, it
is more difficult for them to contribute any fixes or features.

Why sound card documentation should be public

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 sound card documentation public, you really have
contributed something to the Linux development effort.  That should
give you a warm, fuzzy feeling inside.

There other reasons too.  Other operating systems will have an easier
time supporting your hardware.  Many developers will be able to double
check the driver, making it very robust. In the end, this makes your
hardware look good.  People looking to do custom things with your
hardware will be able to so.

With the user base of Linux growing so rapidly, can your company
really afford not to make your sound card 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.  We just need the information that enables us to make
a good sound driver.

Thanks,

The ALSA development team





