Re: [Debian]: SoundBlaster Live
On Fre, Mär 19, 1999 at 09:33:45 +0100, Peter Berlau wrote:
> ein Freund von mir hat eine SB-Live PCI-Slot Soundkarte und möchte Linux
> installieren, jetzt ist er nicht sicher ob sie unter Debian funktioniert,
> hat jemand eventuell diese Karte, oder weiß Näheres hierzu. Gibt es evtl.
> auch alsa-unterstützung für diese Karte ?
So, da jetzt hier so viele Fragen aufgekommen sind, gibts mal die Mails die
ich einigen auch schon privat geschrieben/gevorwärtst habe, hier öffentlich.
Es gab in linux-kernel@ einige heftige Diskussionen über dieses Thema und
IMHO ist der momentane Stand eine lösung, die zwar nicht perfekt ist, aber
mit der man durchaus leben kann, wenn man religiöse Sachen wie "binary-only
kommt mir nicht auf den Rechner" (*) mal außen vor läßt.
Also, lesen und selbst Schlüsse ziehen.
(*) wer nur so denkt sollte sich nämlich mal GANZ SCHNELL mal seinen BIOS
Chip aus dem Rechner rupfen.
--
_ciao, Jens_______________________________ http://www.pinguin.conetix.de
cat /dev/boiler/water | tea | sieve > /cup
mount -t hdev /dev/human/mouth01 /mouth ; cat /cup >/mouth/gulpReceived: (from jens@localhost)
by debian.zuhause.de (8.8.8/8.8.8/Debian/GNU) id VAA10106;
Tue, 23 Mar 1999 21:35:45 +0100
Date: Tue, 23 Mar 1999 21:35:45 +0100
From: Jens Benecke <jens>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Subject: Re: [Debian]: SoundBlaster Live
Message-ID: <19990323213545.E4279@debian.zuhause.de>
References: <[🔎] 19990319213345.A1412@pmurmel.pberlau.users.muenster.de> <[🔎] 19990321214404.A9128@ruhr-uni-bochum.de> <19990322211524.E21747@debian.zuhause.de> <19990322222719.B8844@ruhr-uni-bochum.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.1i
In-Reply-To: <19990322222719.B8844@ruhr-uni-bochum.de>; from Marcus Brinkmann on Mon, Mar 22, 1999 at 10:27:19PM +0100
X-No-Archive: Yes
X-Operating-System: Linux 2.2.3
Status: RO
Content-Length: 10222
Lines: 200
On Mon, Mar 22, 1999 at 10:27:19PM +0100, Marcus Brinkmann wrote:
> On Mon, Mar 22, 1999 at 09:15:24PM +0100, jens@pinguin.conetix.de wrote:
> > Sie *haben* momentan gar keine dokus. Die Chipentwickler (EMU10000
> > Chipset) haben in der Kantine neben den Win95-Softwareingenieuren
> > gefrühstückt und so wurde auch nur EIN Doku-Set für den Chip entworfen -
> > da stehen Programmierinformationen neben Blueprints für die
> > Chipbedampfung.
> Woher hast Du denn diese Anekdote?
darf ich zitieren?
________________________________________________________________________
Message-ID: <017a01be3ea8$6cd85fa0$1b225fc6@warlord-jake.cli.creaf.com>
From: "Jacob Hawley" <jhawley@creaf.com>
To: "Greg Smart" <GSmart@tennyson.com.au>,
"Jakub Gwozdz" <gwozdziu@uci.agh.edu.pl>
Cc: "Linux (Kernel Reflector)" <linux-kernel@vger.rutgers.edu>
To be honest I think that only a very, very small part of the functionality
will be available short term features such as: WAV, Midi, PCM, Simple
effects, Stereo. This is mostly going to be a resource issue, for example
to get where we are today on Win9x (please it is just an example no flames)
it took 6 engineers about 7 months. I expect that the development of the
Linux driver will be slow until we actually have a library / sourcecode to
distribute.
I have literally hundreds of mails today regarding stability of the kernel.
I strongly believe that if the driver isn't architected right it could cause
problems. I understand that there is a strong following of capable
engineers for Linux and that they are willing to assist if not do the entire
job. I think that's great, but I also need to understand what the
ramifications are. I would hate to have a driver go out that was not
capable of being extended to support the full features of our EMU10K1 chip.
NT is mute because it is fundamentally broken, period. That any hardware
works on that OS is amazing.
Creative not unwilling to provide programming information, there simply
isn't any because it hasn't been written. We have almost never given this
type of information out, instead we have exposed functionality through API's
(Windows centric). So we have to work on writing the documents, sample
source code, etc.
I am actively looking to hire engineers to help with this task, because I am
looking for a long term and permanent solution. I am looking to build a
team that will be able to support Linux on more than just one product, which
includes bug fixes, development tools, and feature enhancements.
regards,
Jake
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ausnahmsweise auch mal die private Korrespondenz (aber bitte nicht
weitergeben):
________________________________________________________________________
Date: Sat, 16 Jan 1999 23:59:57 +0100
>From jens Sat Jan 16 23:59:57 1999
From: Jens Benecke <jens>
To: jhawley@creaf.com
Subject: SB live + Linux?
X-Mailer: Mutt 0.93i
Hi,
I recently read this in linux-kernel mailing list:
> CUT The Linux group is partially right. Creative has no plans of
> releasing its intellectual property to the general public. We have spent
> many years and many millions of dollars developing the EMU10K1 audio
> processor, and we do not intent to release it. This is not much different
> than asking Intel to publish the internal details of the Pentium II on
> their website.
I think there is a difference between saying
"to use the reverb features, you have to initialize the chip via this
and this command and then shove data in via DMA using code like this
/* {...} */"
and
"the EMU chip has been developed using 0.xx µm technology and this and
that technology, it contains yyyyyy transistors and a DSP which you can
order at WallMart for $10 (...)".
(Just to make a silly example)
I respect intellectual property, but releasing the chip specifications for
_using_/_programming_ it is IMHO a big difference from publishing the
blueprints. Isn't it?
> However, like Intel, AMD or any other chip manufacture we are planning on
> publishing enough information that interested parties will be able to
> develop drivers / applications for Linux or any other OS. Initially we
See, Intel _did_ release enough information for people to program the chip,
and that was not a big issue. Intel is, in fact, hiring Linux system hackers
to have a look into their INTERNAL chip structures, because Intel wants
Linux to run optimized on Merced the minute the chip is released. (And this
information will kind of be published as well as soon as Linux does run
there, because the kernel is published in source code.)
> plan on working with 4Front Technologies to deliver a Linux driver, this
> is partly because of their expertise. Additionally, 4Front has proven
> their ability to deliver and maintain drivers for Unix based OS's so it
> seems that this is a viable first step for Creative into Linux.
I run AWE32 sound cards at the moment, and I have installed a couple of
S3 Sonic Vibes chip based sound cards because they run with Linux and are
very cheap ($30-35). I would, however, like to use SB Live as soon as there
is a useful Linux driver, and enough published programming specifications
so that developers can write applications to enable the special features of
the chip, like reverb, surround, and so on.
I would appreciate if you could update me on the current status of the
driver. Btw, I recently got AOL to release their network specifications for
Linux developers so that there might very well be a possibility to use AOL
accounts from Linux (if the WinE developers aren't quicker).
Thanks,
--
_ciao, Jens_______________________________ http://www.pinguin.conetix.de
Date: Mon, 18 Jan 1999 11:46:52 -0800
>From jens Tue Jan 19 23:37:41 1999
From: "Jacob Hawley" <jhawley@creaf.com>
To: <jens@pinguin.conetix.de>
Subject: Re: SB live + Linux?
X-Mailer: Microsoft Outlook Express 4.72.3110.1
The current status of the driver is that I have started writing a spec for
the chip, and I am trying to hire an in-house Linux expert. We are working
on releasing a binary as soon as possible, and a developers kit sometime
this summer. We have to produce the binary in order to write the dev kit,
so please don't tell me you don't want it (I have had SOOOO many mails
telling me this already). As soon as we have a chance to release some
documentation we will. Right now I am pairing down a 1200 pg chip document
into something more manageable and releasable.
Jake
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Thu, 21 Jan 1999 12:27:29 -0800
>From jens Fri Jan 22 20:08:55 1999
From: "Jacob Hawley" <jhawley@creaf.com>
To: <jens@pinguin.conetix.de>
Subject: Re: SB live + Linux?
X-Mailer: Microsoft Outlook Express 4.72.3110.1
It's not an NDA issue, the information is NOT usable. We designed the chip
together, I was on the team that architected the chip. The documentation
has details that need to be removed, such as theories of operation for the
logic blocks, formulas, algorithms. None of this is programming
information.
I will have the stuff ready as soon as possible. Stay tuned.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 1 Feb 1999 20:00:11 -0800
>From jens Wed Feb 3 21:07:41 1999
From: "Jacob Hawley" <jhawley@creaf.com>
To: <jens@pinguin.conetix.de>
Cc: <jtaylor@creaf.com>
Subject: Re: SB live + Linux?
X-Mailer: Microsoft Outlook Express 4.72.3110.1
First I don't know the TLA RSN? Second I have already stated that I will be
putting out an SDK as soon as we can pull it together.
>btw, how was the windows driver developed? ;-)
The software engineers looked over the shoulders of the VLSI team.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar gerne erbeten.
Aber bitte nichts religiöses nach dem Motto "binary only Treiber sind
Trojaner" usw. Hast du den Source deines BIOS?
--
_ciao, Jens_______________________________ http://www.pinguin.conetix.de
cat /dev/boiler/water | tea | sieve > /cup
mount -t hdev /dev/human/mouth01 /mouth ; cat /cup >/mouth/gulp
[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-ggi
Subject: I got the Creative Labs position!
From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
Date: 1999-01-28 5:04:06
[Download message body RAW]
NOTE: I am now a Creative employee, but I do not speak directly
for Creative. Anything I do there is subject to their requirements, so
don't take anything but the basics in this announcement as fixed in stone.
With that in mind....
Today I learned that I was chosen for the Creative Labs Linux
kernel sound driver development position that was advertised on
linux-kernel and elsewhere a few weeks back. I will be creating
binary-only Soundblaster Live (OSS and ALSA) drivers to Linux, as the job
posting requested. However, the story only *begins* with sound now! When
I showed them GGI and the fact that I also know Linux graphics systems
programming because of my years with GGI (and my education |->), they
decided to also have me start up an in-house Linux graphics driver
program!
I will be given NDA access to full specs and sample code for all
3Dfx, nVidia, 3DLabs and Rendition chipsets and will be able to produce
fully 2D/3D accelerated binary-only KGI drivers for all of them, which
through the magic of KGIcon will also be fully useable on standard Linux
kernels. Mesa targets for all of these will also be written. When this
is combined with the Soundblaster Live support and the power of the LibGGI
userspace library system, Linux will have as least as much gaming and
graphics capacity as Win32/DirectX. And new hardware will be supported at
release time with Linux drivers, just like Win32.
Prominent game companies have told Creative that they will support
Linux equally with Win32 if the driver and API support is there. It
certainly looks like it will be. How long it will take I can't say right
now, but since I will have access to and use of existing OpenGL driver
code, I think it may happen sooner rather than later. Of course 3Dfx
cards are already supported on Linux by Glide, so if anything happens
there I will need to talk to Daryll Strauss and 3Dfx about that. In any
case, driver support for the other chipsets will come first because they
are currently unsupported at all on Linux 3D-wise.
This is going to impact a lot of aspects of Linux and OSS, so let
me make a bulleted list of them and I'll give my best guess as to what
will happen:
* nVidia's Glide-alike object oriented hardware access library. James
Putnam from nVidia announced this plan some time back, but I have not
heard anything about it since then. I suppose that this would be used if
it was available. I imagine that I will be able to get a good look at it
under NDA, so we'll have to wait and see.
* Existing open-source 2D drivers for 3Dfx and nVidia cards. Initially I
will probably have the video drivers done up as completely self-contained
2D/3D KGI drivers, but hopefully soon we will have a new modular
acceleration system in KGI which will let me go back to open-source for
the basic chipset/clockchip/ramdac/bus io KGI driver components. The 3D
stuff is what has to be kept binary-only.
* LibGGI3D. Back-burner hobby stuff for now. 3D on Linux is all about
Mesa currently. I'll continue to work on it as I have time and energy.
If anyone else wants to pick up the torch for a while, that would be cool
too.
* xBSD support. All the userspace GGI code is designed to be portable and
should run quite well on xBSD, but AFAIK KGI drivers cannot be currently
run on xBSD. There are no license issues as KGI and its drivers are not
GPLed, so that is not the problem. Rather, xBSD does not have the fbdev
driver system and the next release of KGI is not done yet. If these
problems can be fixed (not by me), all of this should work on xBSD as
well.
* Closed-source drivers. Yes, yes, I know. Closed source is evil and all
that. I will of course do my best to see to it that as much source as
reasonably possible *is* released, but expect substantial chunks to remin
closed indefinitely. That is that way it has to be. Creative were quite
clear on this point. Personally, I do not think that open-source is
nearly as big a deal for device drivers as it is for more general types of
programs like operating systems or applications. They are quite boring
sometimes and consist largely of a bunch of one-off hacks. There are also
some proprietary algorithms, though, and I don't think there's anything
untoward about a company wanting to keep trade secrets. It happens all
the time. Be nice, and maybe the hardware companies will be easier to
talk into releasing more specs in the future....
* Cathedral vs. Bazaar-style development. Obviously the presence of a lot
of NDA material and source is going to put somewhat of a crimp in this,
however I do not think it will be much of a problem. I'll try to get back
as much of the "Bazaar effect" as possible by releasing lots of public
betas, but you all must understand that a more traditional commercial
organization like Creative does not like to see buggy half-working
products go out the door. We will see what happens.
* Infrastructure. I'll be doing the usual open-source development stuff:
* A website
* FAQs, HOWTOs, and other documentation
* A mailing list
* A public GNATS bugtracking interface on the website
* A CVS pserver for the public code with both read-only public
access and read-write developer access
* Tinderbox, Bonsai, Bitkeeper, or any other additional present or
future development tools will be made use of as needed.
Whew. Big changes are coming to the Linux world, folks. Watch
for me to announce the website, mailing list, etc soon.
Jon Taylor [taylorj@ggi-project.org]
[prev in list] [next in list] [prev in thread] [next in thread]
About MARC
Want to add a list? Tell us about it.
Progressive Computer Concepts, Inc
Reply to: