On Thu, 5 Jan 2006, Takashi Iwai wrote:
> > If you have sound device without this soft mixing is moved to user space
> > .. but applications do not need know about this even now because all
> > neccessary details are handled on library level. Is it ?
> > So question is: why the hell *ALL* mixing details are not moved to kernel
> > space to SIMPLE and NOT GROWING abstraction ?
>
> Because many people believe that the softmix in the kernel space is
> evil.
This is the usual argument against kernel level mixing. Somebody has once
said that all this is evil. However this is not necessarily correct.
OSS has done kernel level mixing for years. The vmix driver has been used
as the default audio device by hundreds of thousands of customers for
years. We have not received any single bug report that is caused
by the concept of kernel mixing.
Kernel mixing is not rocket science. All you need to do is picking a
sample from the output buffers of each of the applications, sum them
together (with some volume scaling) and feed the result to the physical
device. Ok, handling different sample formats/rates makes it much more
difficult but that could be done in the library level.
> > Why Linux can't provide only OSS API abstraction for user space
> > application ? And/or why ALSA developers want to replace this by
> > mostly bloated and pourly documented ALSA user space API ?
>
> Because OSS API doesn't cover many things. For example,
>
> - PCM with non-interleaved formats
There is no need to handle non-interleaved data in kernel level drivers
because all the devices use interleaved formats. Handling
interleaving/de-interleaving in the application/driver code can be done in
a simple for loop. So why to make the driver/API more complicated with
this.
> - PCM with 3-bytes-packed 24bit formats
Applications have no reasons to use for this kind of stupid format so OSS
translates it to the usual 32 bit format on fly. In fact OSS API does
have support for this format.
> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
Could you be more specific with the above isues?
> - Handling of floating pointer samples
This is not necessary in the kernel drivers because user land apps/libs do
this themselves. However OSS API defines a floating point data type just
in case some future device needs it.
> - Post/pre-effects (like chorus/reverb)
OSS already does this (part of the softoss/vmix driver).
> Forcing OSS API means to force to process the all things above in
> the kernel. I guess many people would disagree with it.
Wrong. This is not an API issue at all. It's an implementation one.
An alternative for doing some operations in the kernel is looping the
audio data through an user land daemon. The application itself is still
using the usual OSS API without knowing anything about any daemons. We
have tested this approach and it works. There just has not been any good
reason to use this approach instead of using kernel space approach.
Passing data through multiple applications makes the latency issues to
accumulate. If you do the processing in the kernel you will hit by the
task scheduling latencies at most once.
The OSS approach is not to make everything in the kernel. Things that can
be done easier in the applications (or in libraries) have been left
out from the API.
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]
