Re: [2.6 patch] schedule obsolete OSS drivers for removal

[tapas <tapas@affenbande.org>]

On Wed, 4 Jan 2006 03:51:09 +0100 (CET)
Tomasz K³oczko <kloczek@rudy.mif.pg.gda.pl> wrote:

> After four years ALSA development quality of sound support in Linux is IMO 
> on the ~same (still bad) level as four years ago. Still to complicated 
> but now more bloated and additionaly not ready for handle fancy gadgets 
> like BT headsets.

Hi,

i want to chime in here in the defense of ALSA. ALSA is vastly superiour
for musicians using linux as opposed to a mere music consumer. Right,
for a music consumer (mp3s, cd's, etc), OSS was probably easier to setup
and use, but there's other advantages of ALSA vs. OSS:

- userspace software mixing (or better software mixing at all. OSS
doesn't have this (the libre version in the kernel, not the closed
source proprietary one)

- userspace resampling (i.e. you have crappy AC97 card that sounds like
shit when resampling automatically? Use the ALSA resampler. It might
sound like shit, too, but at least it can be fixed ;)

- the biggest benefit for me: MIDI routing in between any number of
applications.

- more capable (more complicated yeah but wtf :)) mixer implementation
(the thing to control the volumes, etc)

- way more flexible in handling more than one soundcard/device, etc..

Drawbacks yet:

- complicated device naming scheme. There has been recent changes in
this area to build up a list from which the user can select a device.

- so so documentation: 

-- many apps still use the ALSA api wrongly due to the complex nature of
it and lacking tutorials, etc (for example: ALSA apps should always use
the "default" device if not otherwise indicated by the user. The user
must be able to enter any device identifier string, or additionally
select from the newly built ALSA provided choices list).

-- Users get frustrated often, too, because their distros fail to setup
their ALSA system correctly. Documentation does exist, but it's often of
a technical nature, which is too much for joe user. 

- a single badly behaved OSS app can kill the whole software mixing
setup, leaving the user with seemingly hanging applications. This is
IMHO completely unacceptable. ALSA devs have, more than once, stated
that it is perfectly well acceptable for them :(

- there's two reasons for above:

-- ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
software mixing. As aoss cannot provide OSS emulation to all OSS apps,
the kernel level OSS emu must be fixed. I would probably have a look at
FUSE to redirect OSS access to userspace. I suppose oss2jack could be
modified to use ALSA instead of jack.

-- ALSA's default open mode is "blocking". But the ALSA API uses the
term blocking in two meanings and throws them together into the open
mode of a pcm device. Normally on device files, blocking access means a
read()/write() returns, when there's data which has actually been
read/written to the device. nonblocking access means, read()/write()
return immediately. In ALSA blocking mode means above _plus_ that the
open call will only immediately return (in case of contention) when the
previous user of the audio device has given it up. 

The combination of the last two is deadly :) It leaves users with
nonfunctional sound plus seemingly hanging apps when their soundcard is
not hardware mixing capable. So IMHO, to fix these two issues really is
the most pressing matter of all, but like i said, sadly ALSA devs seem
to disagree (i haven't followed ALSA development that closely lately
though).

> On other systems (MOX, Win*, Solaris ..) on handle sound situations is now 
> better than four years ago. IMO this allow form conclution: generaly 
> current ALSA is step back compare to other systems and probaly Linux need 
> some deeper work then simple polishing sound device drivers.

ALSA is a definitive step forward from OSS. It even is superior to the
original windows sound system (except for ease of configuration - but
windows had no interapp midi routing (extra software needed) plus you
need another audio device driver system (ASIO) to get reliable low
latency operation, and even there it still sucks compared to
linux/ALSA/jack/-rt). MAC OS X almost got it right. Their design has
another drawback though which makes OS X always have ca. 1 period of
latency more. I.e. in terms of low latency operation for musicians with
jackd and -rt kernels, linux is ATM the _superior_ platform.

It is, when setup correctly simply a joy to work with and make music
with.

Regards,
Florian Schmidt