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

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> On Sun, 8 Jan 2006, Olivier Galibert wrote:
>
> > Once again no. Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
>
> But it's quite ineffecient. The kernel must switch tasks at least twice
> or more.
Actually there is just one extra context switch. When the application
using the API interface has finished it's current buffer it goes to sleep
(sooner or later). With no OSS kernel task then the context is
switched to the next process in the ready list. With the OSS task there is
one extra context switch to the task before the inevitable switch to
some other task in the system.

In CPU usage perspective this is nothing significant. This kind of
approach makes only sense if the extra task is going to do some
significant processing. So even if there is one context switch (and
possibly some data copying) related with this mechanism the load caused to
it is microscopic when compared to the actual processing. There is no real
difference when compared to a pure library solution.

What is problem is that context switching delays make it necessary to use
slightly larger buffers. This causes increased latencies which may or may
not cause problems with some timing critical applications. OTOH with OSS
API the application can disable this kind of extra stuff if it needs
"traditional" access directly to the device.

> It's the major problem with the current OSS API.
I don't see there any problem. In particular it's in no way an API
issue. Everything that has been found to be necessary for applications is
included in OSS API and all it has been implemented in kernel space.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@xxxxxxxxxxxxx)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
-
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: [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: [Alsa-devel] Re: [OT] ALSA userspace API complexity
    ... If we have a possibility to remove the code from the kernel ... > Why should there be any need to put library code between the kernel API ... > if somebody wants to emulate the OSS kernel API in library level. ... We have user space solution while you insist to put this ...
    (Linux-Kernel)
  • Sound userspace drivers (fishing for insight)
    ... about userspace sound drivers for Linux and was like O_o so now I'm ... Write sound; context switch; sound ... syscall into kernel space. ... First off how the heck complex is userspace PCI control, ...
    (Linux-Kernel)
  • Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
    ... ocean rewriting 5/6 of the kernel from implicit to ... My applications are *already* written like that. ... (Once you get to user space, ... MMU context switch costs. ...
    (Linux-Kernel)
  • Re: [Alsa-devel] OSS driver removal, 2nd round (v2)
    ... But OSS is kewl and ALSA sucks! ... If ALSA sucks, ... It's very interesting that with some apps aoss method ... But it must be done in kernel because kernel should know these ...
    (Linux-Kernel)