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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
