Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

On Sun, 8 Jan 2006, Hannu Savolainen wrote:

> On Sat, 7 Jan 2006, Takashi Iwai wrote:
>
> > > > 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.
> In such cases it's better to do interleavin/deinterleaving in the kernel
> rather than forcing the apps to check which method they should use.

I don't think so. The library can do such conversions (and alsa-lib does)
quite easy. If we have a possibility to remove the code from the kernel
space without any drawbacks, then it should be removed. I don't see any
advantage to have such conversions in the kernel.

> > 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.
> Why should there be any need to put library code between the kernel API
> and an application that is perfectly happy with it? It is only necessary
> if somebody wants to emulate the OSS kernel API in library level.
>
> A wrapper library with routines like oss_open, oss_write, etc was once
> considered. However we didn't find any good reason to do that (in
> particular because that conflicted with routine names already used
> internally in some important OSS applications).

Bad decision. Again, I feel you're hidding the flexibility against
your feeling that the kernel API is the best enough for applications.
Imagine that the API redirection is or can be also flexible for your
future development.

> What if there is some better way to handle OSS-ALSA interaction than
> library level hooks/emulation. In the short term this may be difficult
> because OSS is binary only and outside the kernel. But in long run OSS can
> hopefully be open sourced which could make it possible to use solutions
> like merging the kernel space drivers together.
>
> Actually I have forgotten what was the reason why you wanted to get the
> OSS API emulated in userland rather than using the previous snd-oss
> module (which worked well other than the API version you emulated was too
> old)?

Stream mixing. We have user space solution while you insist to put this
code to kernel. Simply, we need to go through our library.

>From the end user perspective, don't you think that having an opportunity
to change the API entry point from one to multiple (user space library -
preferred, direct kernel space - last resort) is more flexible for
developers and users? Please, consider this question without any flames
line which API is better and what's better for audio subsystem architects
and what's better for your commercial work.

Jaroslav

-----
Jaroslav Kysela <perex@xxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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: [ANN] WiMAX stack and drivers for Intel WiMAX Link 5050
    ... Please don't build sysfs version checks into the API. ... Rationale is most systems will have a single wimax ... make sure user space stuff can detect that and fail cleanly. ... was compiled for differs from what the kernel offers. ...
    (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: [Alsa-devel] Re: [OT] ALSA userspace API complexity
    ... Nothing prevents the kernel to forward the data to ... Actually there is just one extra context switch. ... With no OSS kernel task then the context is ... API the application can disable this kind of extra stuff if it needs ...
    (Linux-Kernel)
  • Re: [2.6 patch] schedule obsolete OSS drivers for removal
    ... > recommend to use ALSA API directly with apps. ... At the same time the kernel API itself should be suitable to ... > I, at least, have never thought that the OSS _API_ would die. ...
    (Linux-Kernel)
  • Re: The Linux Staging tree, what it is and is not.
    ... Powerlink) driver in staging. ... BTW, the implementation does not follow the kernel style guide, because our company has its own code style guide. ... But it is no easy task to find a common API for all field busses. ... userspace solution like outlined above. ...
    (Linux-Kernel)