Vendor Information: Difference between revisions

From AlsaProject
Jump to navigation Jump to search
No edit summary
(redirect to near identical page)
 
Line 1: Line 1:
{| align="right"
#REDIRECT [[ALSA_Soundcard_Vendor_Information]]
|__TOC__
|}
 
{|
|'''Author:'''
|The ALSA Development Team
|-
|'''Maintained by:'''
|Christopher David
|-
|'''Additions by:'''
|Patrick Shirkey
|-
|'''Last updated:'''
|April 12, 2002
|}
 
== Abstract ==
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.
 
== 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. 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 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.
 
== 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 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.
 
== Our view of NDAs ==
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.
Why soundcard 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 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.
Views on Binary Only drivers
 
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.
Summary
 
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,'''<br>
'''The ALSA development team'''

Latest revision as of 22:54, 9 August 2007

Redirect to:

Retrieved from "https://www.alsa-project.org/main/index.php?title=Vendor_Information&oldid=674"