AlsaProject - User contributions [en]

ALSA contributors

2008-11-12T17:06:09Z

Tongfa: /* Contributors */

== Thanks ==

Many thanks are sent to the people below who help with ALSA development, code, documentation, hardware or ideas. People or companies are sorted in the random order.

If someone is not listed, please, let me (Jaroslav Kysela) know - thank you.

== Contributors ==
'''Jaroslav Kysela''' < perex at suse.cz > 
code: main coder, designer, coordinator 
admin: CVS/WWW/FTP/Mail-List administrator

'''Abramo Bagnara''' < abramo at alsa-project.org > 
code: general hacker, ESS ES-18xx driver, mixer interface

'''Takashi Iwai''' < tiwai at suse.de > 
code: native sequencer hacker, general hacker, EMU8000/10K1 driver, emulator of OSS sequencer

'''Frank van de Pol''' < frank at vande-pol.demon.nl > 
code: ALSA sequencer prototype code and design

'''Jaromir Koutek''' < miri at punknet.cz > 
code: ESS Solo-1 driver

'''Christian Fischbach''' < fishbach at pool.informatik.rwth-aachen.de > 
code: ESS ES-1869 driver

'''Bob Holder''' < bholder at tridentmicro.com > 
code: Trident 4DWave DX/NX driver

'''Steve Ratcliffe''' < steve at parabola.demon.co.uk > 
code: EMU8000 driver, MIDI emulation, native sequencer hacker

'''Paul Davis''' < paul at linuxaudiosystems.com > 
code: WaveFront (Tropez, Tropez+) driver 
code: RME Hammerfall (RME9652) driver 
code: RME HDSP driver

'''Thomas Charbonnel''' < thomas at undata.org > 
code: RME HDSP driver 
code: hdspmixer and hdsploader

'''Anders Torger''' < torger at ludd.luth.se > 
code: RME Digi96 driver

'''Matze Braun''' < MatzeBraun at gmx.de > 
code: ESS Maestro 1/2/2E driver

'''Haroldo Gamal''' < gamal at alternex.com.br > 
code: Korg 1212 IO driver

'''Alan Robinson''' < robinson at vt.edu > 
documentation: corrections for alsa-lib documentation

'''Fred Floberg''' < emng at geocities.com > 
documentation: corrections for alsa-lib documentation

'''Tim Janik''' < timj at gtk.org > 
code: old (up to 0.2.x) alsamixer code

'''Andy Lo A Foe''' < arloafoe at cs.vu.nl > 
code: base amixer code, API testing

'''Paul Winkler''' < zarmzarm at erols.com > 
documentation: manual pages and README for amixer and alsamixer

'''Christopher T. Lansdown''' < lansdoct at screech.cs.alfred.edu > 
code: xamixer

'''Jan ONDREJ''' < ondrejj at salstar.shadow.sk > 
code: alsaconf

'''Thomas Sailer''' < sailer at ife.ee.ethz.ch > 
documentation: for Ensoniq AudioPCI ES1370/1371 and S3 SonicVibes 
demo code: for Ensoniq AudioPCI ES1370/1371 and S3 SonicVibes

'''Chris David''' < cd at chrisdavid dot com > 
other: information for sound card hardware vendors

'''Anders Semb Hermansen''' < ahermans at vf.telia.no > 
code: soundcard selection code for the ALSA driver 
patches and support: patches for mpg123 and driver, active on mailing lists

'''Christopher Butler''' < chrisb at sandy.force9.co.uk > 
code: Sound Galaxy driver 
patches: SB8 code

'''Massimo Piccioni''' < piccio at caronte.csr.unibo.it > 
code: Opti9xx drivers, Aztech System AZT2320 driver 
code: ALS100 driver, ES968 driver, AD1816A driver

'''Henrik Theiling''' < theiling at absint.de > 
code: Marian/Sek'D Prodif Plus driver

'''Valentijn Sessink''' < Valentyn at dds.nl > 
documentation: HOWTO maintainer

'''John Fulmer''' < jfulmer at appin.org > 
documentation: FAQ maintainer

'''Patrick Shirkey''' < pshirkey at boosthardware.com > 
Website/documentation: webmaster and "online docs" creator

== Donations ==

'''MidiMan''' - www.midiman.com 
soundcard: MidiMan Delta 1010, 44, Dio 2496

'''RME''' - www.rme-audio.com 
soundcard: Hammerfall, 3x Hammerfall Light

'''Claus Riethmueller''' < claus at ridi.com > 
soundcard: Hoontech ST Digital 4DWave NX (Trident NX) 
hardware: Hoontech NX DB-I, NX DB-II, ST DB-III 
soundcard: Hoontech Digital-XG (YMF744) 
soundcard: Hoontech AudioTrack DSP24

'''Steven Tseng''' < stseng at fortemedia.com > 
soundcards: 2x ForteMedia FM801 / STAC9704

'''Bob Holder''' < bholder at tridentmicro.com > 
soundcards: 2x Trident 4DWave NX (STAC9704/STAC9708)

'''Frank Altschuler''' < faa at crystal.cirrus.com > 
soundcards: Sound Fusion CS4614/CS4297, Sound Fusion CS4280/CS4297

'''Hynek Petrak''' < hynek at swac.de > 
soundcard: TerraTec 128iPCI (ESS Solo-1 - ES1938S)

'''Michael Stutz''' < stutz at dsl.org > 
soundcard: Turtle Beach Malibu

'''Horace Demmink''' < horace at pathwaynet.com > 
soundcard: UltraSound 32-Pro (STB) 
These soundcards are OEM products of Compaq.

'''Martins Medens''' < martins at parks.lv > 
soundcard: Gravis UltraSound Extreme

'''Roel De Wit''' < MB164 at hi.fontys.nl > '''& Utopia Sound Division''' 
soundbank: beta & final Utopia Sound Bank for InterWave based soundcards

== Other help ==

'''IC Ensemble''' - www.icensemble.com 
documentation: ICE1712 (Envy24) Datasheet

'''Tony Romero''' < Tony.Romero at amd.com > 
documentation: InterWave (tm) IC Am78C201/202 Programmer's Guide

ALSA Soundcard Vendor Information

2007-12-29T01:15:52Z

Tongfa: /* Author: The ALSA Development Team */

{| align="right"
| __TOC__
|}

== Author: The ALSA Development Team ==

maintained by Christopher David (cd at chrisdavid.com) 
additions by Patrick Shirkey (pshirkey at boosthardware.com)

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 [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 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.

== 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
[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. 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, 
The ALSA development team

== Related links ==

*[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]
*[[ALSA Blacklist]] Cards for which necessary information is not available to enable driver development
*[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]
*[http://www.kroah.com/log/linux/free_drivers.html Greg Kroah-Hartman offers free driver development]