From alsa-devel-owner@alsa.jcu.cz  Sun Feb 28 21:24:25 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 VAA04138
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 21:22:45 +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 MAA22385
	for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 12:19:28 -0800 (PST)
Received: from kduffey ([10.143.1.75]) by godzilla.inprise.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA9D
          for <alsa-devel@alsa.jcu.cz>; Sun, 28 Feb 1999 12:19:26 -0800
Message-Id: <3.0.32.19990228121957.0095e990@mail.inprise.com>
Date: Sun, 28 Feb 1999 12:19:58 -0800
To: alsa-devel@alsa.jcu.cz
From: "Kevin Duffey" <kduffey@inprise.com>
Subject: Re: Trident's contribution, a draft 
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

Hi.

>Binary drivers are not an acceptable solution to me and to many other people.
>I've discussed the reasons for this previously on this list.  Check the
>archives.  I'll send you a pointer if you can't find it.

Hmm..well, my take on it is this. While I agree with your reasoning, I also
disagree for a few reasons. First, if Creative and some others NEVER
release the specs for open source, then ALSA will NEVER support them.
Period. Thats bad. Creative is by far the most important soundcard you
should support. The SB Live sold more than 1 million units in 4 months!!
With new hardware coming, and more being sold, that a LOT of potential
linux users that wont be able to hear ANY sound on their soundcards,
including me. It also makes it that much harder to develop software to work
with these soundcards. There are others too. I don't see any support for
any soundcards that use system RAM based sounds. Maybe you can tell me if
the SonicVibes support has the ability to load DLS banks? If not, then
really the S3 stuff only supports AUDIO playback, and not the best features
of the soundcard.

My understanding of ALSA is to provide a robust COMPLETE sound solution for
linux users, that is "free". The only problem with the GPL is that a LOT of
current developers/vendors do not agree with releasing their source code
for ALL to see. Part of the reason behind OOP was to "hide" the details so
other developers using your code dont see your source..they only know how
to use it. I am all for GPL, and indeed plan on releasing my own music core
as GPL (eventually). But..the one MAJOR bottleneck with linux is trying to
get hardware and software vendors alike to JOIN linux and build their
products for linux, whether its drivers, scanners, cameras, etc. If we say
"sorry ALSA users, we will never support SB Live because its a binary only
driver and we dont except that" you have pretty much shut off more than 1
million users and counting from using ALSA. That means your "competitor"
OSS (I think thats them) would have potential to support them and others,
and thus have a much larger user base than ALSA. 

I believe if OSS gets that much support (both hardware and end users) it
will be hard for ALSA to really offer a better solution. While a lot of
linux users would use ALSA, I think as linux becomes a more viable choice
of OS over MS windows, more people would be willing to pay a small fee, or
whatever to have support for their hardware. I would imagine at some point
if linux really does start showing up in the desktop arena for average
users, there will have to be some way for hardware users to support it, and
if ALSA says "you must make source code available and give it away free,
and allow others to modify it and give it away" that the alternative of
"just make us a binary driver to give complete support for your hardware"
looks much better to a lot of potential vendors. And..if those vendors
start going with say OSS in this case, then the end users will follow suit. 




>No, this is not something we want to encourage.  We want to spit on Creative
>and its driver.  Turn our backs and tell them that we simply are not
interested
>in playing that game.  If they don't want to release specs, fine, we don't
>want to buy their cards.

Well, thats fine if that your look. Personally, their soundcard for the
price and performance is by far the best one out there. No matter how much
spitting you do..they dont care. They will support the Open Sound instead,
and Open Sound will dominate the linux sound capabilities and more
developers will use the Open Sound API to make sound then ALSA. I dont mean
to discourage in any way, please dont misread what I am saying. I read Open
Sound and ALSA and immediately saw ALSAs potential. But by closing off the
world to over 1 millino SB Live/Value users, and counting, and other cards
like MX-200, MX-300, Monster Sound, etc that use RAM based sounds, this
could very well hurt the ALSA project. 

>A way around the restrictions?  Those restrictions are the very core of the
>GPL.  They're there to help protect you and your freedom.  They're the reason
>why we use the GPL in the first place.
>
>If you don't want that kind of protection, then you don't use the GPL.
That's
>what the BSD style licenses are for.

>If companies don't want to release driver source, then they need to release
>hardware interface specifications.  If they release neither source nor specs,
>then they simply are not worth doing business with.
>
>You're right, thought.  ALSA does need good support for quality hardware.
>In the short term, it would be good if ALSA could accept these drivers, but
>the long term detriments far outweigh those small benefits.

I disagree. For what I said above, the short term support you get now may
go a long way in proving to these vendors that the ALSA spec is the right
way, and may eventually release source code, etc. 

On the other hand, why is it necessary to release source code to drivers
for soundcards? Almost all end users of ALSA will never need to worry about
HOW the driver was written or ever touch it. Mostly software developers of
music products are the only ones that may have a curiousity to see the
driver in detail, and at that, they may never need to actually change it.
Besides, some companies would look at someone "changing" their code and
re-releasing it as a BETTER or ENHANCED driver as if THEY themselves were
incapable of doing so. That could look bad on a well established company.

My 2 cents worth.


Kevin Duffey
kduffey@inprise.com

