At Fri, 6 Jan 2006 03:36:47 +0200 (EET),
Hannu Savolainen wrote:
>
> On Fri, 6 Jan 2006, Marcin Dalecki wrote:
>
> >
> >
> > No I do not. How do you dare to assume I do?
> > I never ever did ask for any support on behalf of the ALSA bunch...
> > We are just discussing the merits of one sound system design
> > over another one (without design).
> Which is really a good subject to discuss about (LKML may not be the right
> place for this). ALSA has been in the official kernel for two years now so
> might this be a good time to look back?
>
> There are two very opposite approaches to do a sound subsystem. The ALSA
> way is to expose every single detail of the hardware to the applications
> and to allow (or force) application developers to deal with them. The OSS
> approach is to provide maximum device abstraction in the API level (by
> isolating the apps from the hardware as much as practically possible).
Agreed, it's a good point.
Note that for long time, I've commented that I myself do _not_
recommend to use ALSA API directly with apps. Rather I've recommended
to use other portable libraries with ALSA/other backends. Writing an
app with alsa-lib is just like to write a graphical program with X11
lowlevel library without any toolkits...
> Both ways have their good and bad sides. During past years the ALSA
> advocates have been dictating that the ALSA approach is the only available
> way to go (all resistance is futile).
Heh, it's natural that developers think their own things work better
:)
> But after all what is the authority
> who makes the final decision? Is it the ALSA team (who would like to think
> in this way)? Or do the Linux/Unix users and audio application developers
> have any word to say?
I, at least, have never thought that the OSS _API_ would die. Since
they have existed, they will exist. The question on LKML should be
rather the implementation (for apps it doesn't matter how the sound
system is implemented as long as it keeps API).
In the implementation of OSS API, there is a clear bottleneck: you
have to implement everthing in the kernel level because of its
definition. Remember that the original thread started from the
reduction of the kernel codes. Putting more stuff which could be done
better in user-space is a major drawback, IMO.
Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
