Re: [OT] ALSA userspace API complexity

[Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>]

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 ?

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 ?

Next thing: look again on diffrent types sound devices. What do you have ?
Sound  output/input device(s) wich acan be oppened with diffrent sampling 
rates and diffrent samle sizes or only constatns sample rates/sizes, mixer
devic(s), midi ... all ot them CAN BE abstracted to form with hidded ALL
hardware details. Problem with growing abstraction size ocurres ONLY when 
some new hardware will provides new hardware sound part class/type.
Generaly this NOT OCCURRES in case sound devices.
So .. I don't see your "kernel should be bigger and bigger". If you 
want continue please describe this.

BTW X11: please don't use X11 examplary. Despite the fact that ther are 
quite a lot of people working around it's defficiencies in a moderately 
successfully way, X11 has to be considered a piece of rotten bloated 
mindless utter crap and by no way as an exemplary piece of software design 
exercise.

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 ?

- KNOWN FACT is OSS provides simpler API for user space for handle
  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 ?

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*