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

[Jaroslav Kysela <perex@suse.cz>]

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@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs