Re: [OT] ALSA userspace API complexity



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



Relevant Pages

  • Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id)
    ... kernel representation. ... If the state can be inferred from user space it is visible to user ... In the worst case today we can restore a checkpoint by replaying all of ... Checkpoints coordinated between multiple containers or real ...
    (Linux-Kernel)
  • Re: [OT] ALSA userspace API complexity
    ... Why we have X servers in user space (and only some supporting code is in the kernel) then? ... Can you do this with ALSA way? ... comercial OSS have ALSA emulation and ALSA have OSS emulation. ...
    (Linux-Kernel)
  • Re: Things that Longhorn seems to be doing right
    ... Updating a user space database every time ... >is just as bad as putting an SQL optimizer into the kernel. ... Well, since I don't think that SQL belongs in the filesystem, and I ...
    (Linux-Kernel)
  • Re: [Devel] Re: [PATCH 0/9] OpenVZ kernel based checkpointing/restart
    ... That is why we prefer in OpenVZ to do all the job in kernel. ... with the same distribution. ... The distributed protocol used for restart is ... from user space, ...
    (Linux-Kernel)
  • Re: syscalls implementation
    ... In user space, the system calls are stubs in a library that traps into ... the vector code generated from syscalls.master in the kernel. ... stack, and then a trap is issued by ... argument pointer are passed to the system call. ...
    (freebsd-hackers)

Quantcast