Re: [OT] ALSA userspace API complexity

Takashi Iwai
2006-01-05T16:14:43Z

At Thu, 5 Jan 2006 16:07:02 +0100 (CET),
Tomasz K³oczko wrote:
>
> On Thu, 5 Jan 2006, Jaroslav Kysela wrote:
>
> > On Thu, 5 Jan 2006, Tomasz K³oczko wrote:
> >
> >> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
> >
> >>> Well, the ALSA primary goal is to be the complete HAL not hidding the
> >>> extra hardware capabilities to applications. So API might look a bit
> >>> complicated for the first glance, but the ALSA interface code for simple
> >>> applications is not so big, isn't?
> >>
> >> Sorry Jaroslav byt this not unix way.
> >> Wny applications myst know anything about hardware layer ?
> >> In unix way all this details are rolled on kernel layer.
> >
> > It means that you are saying that kernel should be bigger and bigger.
> > Please, see the graphics APIs. Why we have X servers in user space (and
> > only some supporting code is in the kernel) then? It's because if we
> > would move everything into kernel it will be even more bloated. The kernel
> > should do really the basic things like direct hardware access, DMA
> > transfer etc.
>
> List all neccessary feactures and abstract them. Below this layer you
> can plug to this all device drivers. Where is the problem ?
> Cureent way moves some importand details like mixing to user space
> library.
> All abstraction are NOW coded but some parts of this abstraction are on
> library level and you are wrong because this still ONE abstraction
> (not multiple/growing).
> Moving some patrs of this abstraction to user space level DISSALLOW secure
> manage because you do not have *single point of entry to this layer*. Try
> plug library abstraction to SELinux layer. Can you do this with ALSA way ?

I don't understand this. The alsa-lib doesn't skip the h/w access.
It still accesses the device file as usual, open/close/ioctls. If the
h/w to do softmix is restricted, you can't use it, too.
Or, am I missing something else?

> If you have sound device with hardware mixer(s) ALSA now work
> transparently.
> 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. The discussion aboult this could be a long thread.

(snip)
> In case ALSA now questions are very basic:
>
> - all hardware mixers are very simillar with very izomorphic interface
> (read this as: this can be very easy abstracted) and we have only one
> other case with soft mixing when this hardwware must be emulated in
> software .. so all this details can be rolled to one leyer on kernel
> level.
> So: why all mixing details are not in kernel space ?

The problem is not the interface but the implementation.

> - KNOWN FACT is OSS provides simpler API for user space for handle
> usual cases.

Please define "usual cases".

> 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
- PCM with 3-bytes-packed 24bit formats

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
- Handling of floating pointer samples
- Post/pre-effects (like chorus/reverb)

Forcing OSS API means to force to process the all things above in
the kernel. I guess many people would disagree with it.

Takashi