From alsa-devel-owner@alsa.jcu.cz  Tue Mar  2 18:57:29 1999
Received: from linuxmaster.corel.eng (internet.corel.ca [209.167.40.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA17959
	for <alsa-devel@alsa.jcu.cz>; Tue, 2 Mar 1999 18:56:54 +0100
Received: (from news@localhost)
	by linuxmaster.corel.eng (8.8.7/8.8.7) id MAA02657
	for alsa-devel@alsa.jcu.cz; Tue, 2 Mar 1999 12:56:22 -0500
From: uo3fieoe@umail.furryterror.org (Zygo Blaxell)
Subject: Re: (SB Live) Free drivers or not? (fwd)
Date: 2 Mar 1999 12:56:20 -0500
Message-ID: <7bh8o4$tpr$1@naga.corel.eng>
References: <3.0.32.19990301095540.0096cb20@mail.inprise.com> <Pine.LNX.4.05.9903011333590.27296-100000@screech.cs.alfred.edu>
To: alsa-devel@alsa.jcu.cz
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

In article <Pine.LNX.4.05.9903011333590.27296-100000@screech.cs.alfred.edu>,
Christopher T. Lansdown <alsa-devel@alsa.jcu.cz> wrote:
>> But, I am saying, while I dont want to see Linux ever so close
>> ended as Windows is, it would be very nice to see some sort of
>> standardization for specific areas of computing, such as multimedia, 
>	This one is just vacuous.  Sound: OSS, Video: X, CDROM: it's a
>plain old drive.  What else falls under the umbrella of multimedia?

Synchronization, performance, and codecs are the big outstanding
multimedia problems.  Video is nice but not if it's +/- 1/2 second out
of sync with the audio (and not even out of sync by a constant), or if
you spend 50% of your CPU time copying the video data out of the kernel
buffer over the dog-slow AGP bus, or if you can't decode video frames
because they are stored in Radius Cinepak format.  Multimedia CDROMs tend
to come in the format-of-the-week to defeat reverse engineering efforts
(yeah, it slows us down by a whole week :-).

All of these are currently supported in Linux but not very well.  Sound
support is the purpose of the ALSA project of course.  video4linux2 is
a huge improvement over video4linux1, but it still involves one extra
memory copy per frame.  All I need for video playback is a 24-bit frame
buffer and a lot of CPU bus bandwidth; a 3D action game is a different
beast entirely.  CD-ROM support is mostly there (at least I've been able
to find anything I need and do the integration and/or development myself)
but last time I checked DVD isn't there yet.

>> scanners, 
>	The SANE project is working on that.  They have a decent number of
>scanners support at the moment, IIANM

The SANE project is just plain scary--everything done through dynamic
..so's, full autodetect and autoconfigure, even network-transparent
scanners.  Nice.  I spent less time _setting up_ my UMAX scanner under
Linux, downloading SANE, reading the manuals, integrating SANE with GIMP,
and getting the configuration just right than I did trying to do _one_
scan with a TWAIN user interface under Win95 on an HP scanner that was
_already_ installed and configured.  Even worse, the output file generated
by SANE was useful, while the TWAIN user interface (which shall remain
nameless) left me with a multi-megabyte proprietary file format that I 
couldn't read anyway.

>> printers, 
>	lpd.  There are filters available for a decent number of printers,
>though things can be sticky.  This area needs improvement, but lpd will
>probably still be the standard, just an improved lpd.

Maybe someone should start the PANE project (Printer Access Now Easy)
and implement a front-end/back-end system for printers similar to the
SANE architecture.  GGI is probably more likely to achieve this by
implementing support for printers as generic graphics devices, assuming
that GGI is not too tied down in the raster graphics world.

lpd itself is really very seriously limited as anything other than a
network transport.  For robustness you'd want the data format issues
resolved in user space on the client side; on Linux systems it's really
cheap to have an application fork to do any extended processing in
the background, but really dangerous to try to invoke something like
ghostscript--or even worse, a third-party printer driver that had
buffer-overrun bugs--from the context of a network-accessible daemon.

>*WINE progress.  The WINE (Windows Emulator) project is making great
>strides.  You can run, fairly well, some versions of word now.  I don't
>know what the future of wine holds, but it is probably pretty good.  I
>know of a bunch of games that apparently run very well under wine, and
>I've heard about a bunch of productivity programs that work well under
>WINE.

We have a guy here working on Corel Presentations, which requires
DirectX support.  I'm told his job basically amounts to making Quake II
and StarCraft work: after that, so I'm told, Presentations is trivial.
Remember: you didn't hear this from me.  ;-)

>> Then again, I dont know if Linus and the Linux OS aims to do that or not. I
>> would hope so..just to break the MS empire. But who knows.
>	Actually, Linus has publically stated that he hopes that Linux
>grows to around 30% of the market, but no more.  He wants interoprative
>diversity, not really world domination.  As long as everyone works with
>each other, diversity is definitely the way to go.

Replacing one empire with another is not the goal; if it was, we'd all be
using MacOS or Java.  Destroying the existing empire and preventing
a new one from forming is the goal.  Ultimately it doesn't matter who
the 90% industry player is--whoever they are, they will be harmful to
the other 10% just by existing.

-- 
Zygo Blaxell, Linux Engineer, Corel Corporation, zygob@corel.ca (work),
zblaxell@furryterror.org (play).  It's my opinion, I tell you! Mine! All MINE!
Size of 'diff -Nurw [...] winehq corel' as of Tue Mar  2 12:14:00 EST 1999
Lines/files:  In 4440 / 4, Out 13185 / 221, Both 17550 / 223

