Sound Blaster Live

[Petr Mosnicka]

Alda wrote:
> 
> Zdravim,
> nevi nekdo jestli existuje podpora pro $subj$. Popripade, kde k tomuto
> tematu neco najit (samozrejme ve vztahu k linuxu)
> 

Forwarduji zpravu z linux-ggi...

petr
--
Petr Mosnicka
Penguin Audio        http://home.eunet.cz/moshna/pa

----------------------------------------------------------------------
List:     linux-ggi
Subject:  I got the Creative Labs position!
From:     "Jon M. Taylor" <taylorj na 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 na ggi-project.org]