Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

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 (hannu@xxxxxxxxxxxxx)
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/