Re: [OT] ALSA userspace API complexity

[Takashi Iwai <tiwai@suse.de>]

At Fri, 6 Jan 2006 01:06:27 +0200 (EET),
Hannu Savolainen wrote:
> 
> 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.

Yes, but which library?


> > >    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.

Many RME boards support only non-intereleave data.

> 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.

Well, this is stupid but very popular nowadays, unforunately :)


> > 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?

I meant to split channels of a single device to different processes
(e.g. front/rear/clfe for each).  (I know it's doable but the question
is how to implement it.)


> > - 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. 

Indeed.  But you know that almost all "OSS" applications access
directly the device files.  There is no room to put a library to solve
these things in user-space.


> 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.

Yes, I thought of the similar thing...  But, is it really a preferred
approach?


> 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.

Basically, it's not 100% fault of OSS, IMO.  But, looking at the
reality, apps do access directly to the kernel.  It's worse in the
case of binary-only apps like flash or skype.  To support these
things, the only "realistic" (OSS-ish) solution so far is to implement
the conversion routines in the kernel level.


Takashi