From alsa-devel-owner@alsa.jcu.cz  Tue Mar  9 00:59:22 1999
Received: from druid.inprise.com (druid.inprise.com [143.186.11.70])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id AAA05367
	for <alsa-devel@alsa.jcu.cz>; Tue, 9 Mar 1999 00:58:59 +0100
Received: from godzilla.inprise.com (mail.inprise.com [10.186.1.4])
	by druid.inprise.com (8.8.8+Sun/8.8.7) with ESMTP id PAA27254
	for <alsa-devel@alsa.jcu.cz>; Mon, 8 Mar 1999 15:55:34 -0800 (PST)
Received: from kduffey ([10.143.1.75]) by godzilla.inprise.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA607A
          for <alsa-devel@alsa.jcu.cz>; Mon, 8 Mar 1999 15:55:34 -0800
Message-Id: <3.0.32.19990308155611.0097ebd0@mail.inprise.com>
Date: Mon, 08 Mar 1999 15:56:11 -0800
To: alsa-devel@alsa.jcu.cz
From: "Kevin Duffey" <kduffey@inprise.com>
Subject: Re: New call.html
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

<excerpt><center><bold><bigger><bigger>

</bigger></bigger></bold></center></excerpt><<<<<<<<


Some gramatical changes. A period here, change there. Nothing too big.


>>>>

<excerpt><center><bold><bigger><bigger>ALSA Soundcard Vendor 
Information

</bigger></bigger></bold>  

<bold><bigger>Author: The ALSA Development Team

</bigger></bold>      maintained by Chris David 

		last updated: March 8, 1999 

</center><bold><bigger>

Abstract

</bigger></bold>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. 

<bold><bigger>Background

</bigger></bold>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 
HREF="http://www.gnu.org/copyleft/gpl.html">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 

</excerpt><<<<<<<<

CHANGE: (note the old says sequencer..but not everyone will only use a
sequencer. There are many other possibilities for music and sound
applications. Using sequencer "may" lead some to think that ALSA is only
for sequencers. 


low level soundcard drivers, all the way up to a high level music or
sound applications. This document is mainly concerned 

>>>>

<excerpt>with what is needed to develop the low level soundcard drivers. 


ALSA plans to be part of the mainstream Linux kernel when it is ready. 
ALSA is fully compatible with OSS/Lite Mixer and PCM interfaces.  ALSA
offers better native interfaces that new applications can use.   

<bold><bigger>What we need to write good drivers

</bigger></bold>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 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.) We would
like the source code for firmware.  It is not required that it is given
to us. For firmware, we do not require it. 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 the 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 additional information, that would be great! 
Generally, we do not have 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. 

</excerpt><<<<<<<<


>>>>

<excerpt><bold><bigger>

Our view of NDAs

</bigger></bold>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 do 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 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 soundcard documentation
because they are not part of the NDA agreement, it is more difficult for
them to contribute any fixes or features. 

<bold><bigger>Why soundcard documentation should be public

</bigger></bold> 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 warm, fuzzy penguin feeling inside. 


There are 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. In addition, 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. 

<bold><bigger>Views on Binary Only drivers

</bigger></bold>  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
<<http://lwn.net/1999/0211/kernel.phtml>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. 

* These drivers must not use ALSA for technical support whatsoever! We
place a requirement on binary-only drivers that they must include a
notice stating the following. "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
have many possible variations that require different builds. 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. Its just
that 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. 

<bold><bigger>Summary

</bigger></bold>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? 


Thanks, 

The ALSA development team 

----------------

<bold><bigger>

Related links

</bigger></bold>

* <<http://alsa.jcu.cz/call.txt>This document in plain text

* 

* <<http://www.precisioninsight.com/alspaper.html>Managing Graphics
Hardware Vendor Relationships in the Linux Developer Community

* 

* <<http://www.news.com/News/Item/0,4,30027,00.html>Linux shipments up
212 percent

* 

* <<http://www.heise.de/newsticker/data/odi-13.01.99-000/>Microsoft sieht
Linux pro Jahr um 960 Prozent wachsen

* 

* <<http://alsa.jcu.cz/black.html>ALSA blacklist

* 

* <<http://www.gnu.org/copyleft/gpl.html>Gnu General Public License  

* 

* <<http://lwn.net/1999/0211/kernel.phtml>Linux Weekly News article
concerning recent binary-only drivers in Linux 

* 



----------------

</excerpt>



Kevin Duffey

kduffey@inprise.com

