Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Sun, 09 Jul 2006 11:18:19 -0400
Lee Revell <rlrevell@xxxxxxxxxxx> wrote:

> On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> > Adrian Bunk <bunk@xxxxxxxxx> writes:
> > > 
> > > Q: What about the OSS emulation in ALSA?
> > > A: The OSS emulation in ALSA is not affected by my patches
> > >    (and it's not in any way scheduled for removal).
> > 
> > I again object to removing the old ICH sound driver.
> > It does the same as the Alsa driver in much less code and is ideal
> > for generic monolithic kernels
> 
> It doesn't do the same thing - software mixing is impossible with OSS.

Only GPL'ed version has this limitation - its just not implemented because all this
GPL'ed OSS is abandoned.
The commercial version from www.opensound.com does input/output mixing
in software in kernel space.
It is free for home/personal use and only one thing you must do is to update
it regularly - once every 4 months. It works out of the box with 2.6.xx kernels and you don't
need additional sound daemons or hidden library threads (ALSA approach).
It has included scripts for module compilation in case of kernel change
and you can also have automatic updates and mixer settings restore without need
for instaling additional software packages.
It has also text and graphical configuration tools and mixers.
So users have still a choise and they will chose a product which best fits they needs.

>From my point of view ALSA has many advantages if you want to dig in the card driver
buffers/period etc. settings but lacks ease of use and some of simple in theory
functionality is a pain - device enumeration or switching output mode/device
without restarting apps or rewritting them so they have special function for that purpose.

esd, arts, jackd, polypd and other prove that ALSA is not enough
and its functionality is far from perfect.

We have more and more audio devices - USB and Bluetooth ones - and
we need switch ouput from one to other device without changes in apps.

So better is to have some virtual sound device, then some mixing/effects/plugins
modules and then true sound device or network stream. Normal app just doesn't
need to now mutch about sound device. It just sets basic audio parameters
and plays. Is ALSA going in that direction?

ALSA api is too complicated - too many possibilities to obtain the same effect -
and additionaly there is no good docs how to use this api properly.
Some methods don't work in some situactions - callback method for example uses signals
and in case of apps which turns some signals off there will be no sound at all.

Developers of ALSA say that they have no time to write docs. True - but including in kernel
some functionality for which users have no good docs is not good for anybody.
We have many programs which use ALSA and don't work properly.
Forcing users to use ALSA is some kind of misunderstanding in this situaction.

We have also almost no docs about ALSA drvier <-> ALSA lib interface which is a strange
in case of GPL'ed software if we want to implement a new hw driver.

So is ALSA really what the users need? The future is unknown.
 
Regards
-- 
Adam Tlałka       mailto:atlka@xxxxxxxxx    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@xxxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/