Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

On Tue, 11 Jul 2006, Adam Tlałka wrote:

OSS kernel compatibility is only partial and aoss method is not fully

Partial? Elaborate please. And talk about OSS drivers in 2.6 kernel.

b) you're requestion to avoid scheduler participation in the audio
processing and yes, we have this solution already (dmix), but not in
kernel

just the contrary - scheduler participation is needed to avoid sound
distortion and missing samples

Nope. You're missing that dmix does not add any extra latencies, because
samples are written directly to the DMA buffer.

c) as you said, the kernel should contain only critical code to drive
hardware, sample rate conversion, sample format conversions and so on
are NOT part of this code in my opinion

if doing this operations behind application back can lead to not delivering
data to kernel driver in time then these are time critical operations too!

Sorry, but you have limited resources (CPU power). It's completely
irrelevant, if you do processing in the user space or in kernel (in my
opinion it's even worse to do such things in the interrupt context).
It's probably better to think how to instruct scheduler to wake up
the sound applications as soon as possible.

ALSA in lib way has its limitations and drawbacks and adding more
feaures this way leads to more complications only IMHO.

Which limitations? We can do all things like OSS API. The whole point of
all problems is that OSS has the API entry point in syscalls which is
quite bad so the redirection is problematic.

Yes but what a complicated way. And you cannot use kernel OSS emulation
and ALSA aware apps at the same time. Also aoss with dmix are in
conflict with jackd for example.

??? Elaborate. It should work.

Kernel redirector is not a bad solution - there should be some kind of
interface for such redirectors for different purposes. netlink device
maybe? For example you should redirect all these traffic to some RT
daemon doing all job.

I would prefer probably a network lowlevel ALSA driver. You'll get the
network transparency as benefit.

Same with filesystem redirections. I hate these special gnomevfs or kdeio
helpers which forces to rebuilding apps with more and more libs.
Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
This is the Windows way of doing uncontrolled mess.
This plugin architecture without mandatory kernel access control leads
to serious security risc.

Unfortunately, more functionality requires more code. You have to deal
with bloating the user or kernel space.

Jaroslav

-----
Jaroslav Kysela <perex@xxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Relevant Pages

  • Re: Is it time for remove (crap) ALSA from kernel tree ?
    ... They are all based on HD audio which is supported by OSS. ... driver driver still needs some work which was one of the reasons why we ... The HD-audio is still messy on ALSA, ... We have no intention to push OSS back to the kernel or to replace ALSA. ...
    (Linux-Kernel)
  • Re: Alsa, the easy way
    ... >> alsa? ... > Ah, forgot to mention that I'm still using, kernel 2.4.27. ... Make sure that the OSS driver is not in /etc/modules, ...
    (Debian-User)
  • Re: [Alsa-devel] OSS driver removal, 2nd round (v2)
    ... And talk about OSS drivers in 2.6 kernel. ... quite bad so the redirection is problematic. ... I would prefer probably a network lowlevel ALSA driver. ...
    (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)
  • 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)