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

[Alistair John Strachan <s0348365@sms.ed.ac.uk>]

This is a superb, informed summary of the pros and cons of ALSA.

I urge the ALSA developers to consider each point carefully so we can try to 
make ALSA even better.

On Wednesday 04 January 2006 10:37, tapas wrote:
> 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

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/