On Sat, 7 Jan 2006, Takashi Iwai wrote:
> > 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...
Takashi, I knew you are smart enough to realize this. What is needed at
the kernel level is a driver API that is strong enough to provide all the
functionality needed to implement good user land libraries (including
alsa-lib). At the same time the kernel API itself should be suitable to
be used in mainline applications. At this moment Jack is already used by
most high end Linux sound apps which is good approach.
> > 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
> :)
This is natural and acceptable. What is not acceptable is that 1000's of
existing applications are forced to be converted to use some new API
because the original one is seen as deprecated by the developers of the
new one. Or to be forced to access the devices through some
LD_PRELOAD hack and redundant layers of library code that provide very
little if any added value.
> > 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).
This is OK as far as long as the approach taken doesn't make it impossible
to develop the OSS API as a pure kernel API as it has been designed to be.
Development of OSS is still continuing as a stand alone project. In the
long term it will be open sourced and possibly given to some Xorg like
consortium. How soon (if ever) this is going to happen is mostly a funding
issue.
The ALSA kernel API is not documented and it's not intended to be
used directly by the apps. If OSS is moved behind some user land wrappers
then there is no kernel level API available for (embedded) software
developers. Also it's very hard to believe that Linux maintainers love to
have a kernel API that is only known to bunch of current ALSA developers
and requires use of given library implementation (directly or indirectly).
A challenge will be finding a way how both OSS and ALSA APIs can coexist
without disturbing each other. There are many ways (better than
artifically forcing OSS API to be emulated in user land). I'm confident
that something can be worked out.
> In the implementation of OSS API, there is a clear bottleneck: you
> have to implement everthing in the kernel level because of its
> definition.
I very well know this limitation. I have never claimed that everything
can or should be done in the kernel. There is lot of stuff that can be
done better in user land library/app code. OSS itself doesn't contain any
library code because we think there are other developers that can do
libraries better than we.
> 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.
Completely agree. There are many things such as effect plugins that cannot
be done in kernel space (or technically they can be done but they should
not be done).
However there are things like endianess conversions that can be done
equally well in kernel space (while in an ideal world they belong to
userland). Such simple operations don't take longer than nanoseconds to
execute and they make implementing the user land code simplier.
And surprise surprise there are things that can be done much better in
kernel space than in userland. If some processing is done in the interrupt
handler there are no scheduling latencies involved. Interrupt handlers
fire in microseconds so the device can be programmed to interrupt after
each sample. This in totally cannibalises the system by raising interrupt
overhead significantly (up to 5-20%). It is known that kernel developers
don't like this kind of core porno at all. However if zero latency audio
processing is the primary purpose of the system then this is the way to go.
Avoiding kernel code that can be handled in userland is the rule. But as
you may see even this rule has some exceptions.
Best regards,
Hannu
-----
Hannu Savolainen ([email protected])
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
-
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]
