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

[Jaroslav Kysela <perex@suse.cz>]

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

> On Mon, 10 Jul 2006 20:39:03 -0400
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > > ALSA lib has something like 7 different methods just to play a sound.
> > > Their view of "low level" is quite interesting.  Using it is pure
> > > hell.  Debugging what you've done is worse.  And don't bother to hope
> > > that your code will still work in six months.
> > > 
> > 
> > A small FAQ:
> > 
> > Q: But OSS is kewl and ALSA sucks!
> > A: The decision for the OSS->ALSA move was four years ago.
> >    If ALSA sucks, please help to improve ALSA.
> 
> The problem is that ALSA is done a Windows way with too many not always 
> working ways of obtaining sound and lack of user docs. So there is still 

The docs are available: 
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

If you have some comment or idea to improve it, please, post it to 
the relevant mailing list.

> the general question: Is it the proper way? How I can help improve ALSA 
> if I just dislike its design?

Then it is your problem. I've not seen a single problematic technical 
information from your mails.

> I spent some time improving dmix and aoss in the past. I have a version 
> of aoss which uses callbacks and works properly with some not properly 
> written OSS apps. It's very interesting that with some apps aoss method 
> gives better sound A/V synchronization then using native ALSA app 
> support ;-). But callbacks not always work and LD_PRELOAD method is 
> generally not secure and some kind of a hack. So I just don't think it 
> could be improved with it's current design. In my opinion it should work 
> out of the box without need to rewrite old or proprietary apps and 
> messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with 
> all input/output mixing of course. Userspace thread method leads to many 
> problems - swapping and rescheduling leads to bad acustic effects. Of 
> course if an app can't supply data when it should we can't do anything 
> but if scheduling or swapping causes problems the design seems to be 
> bad.
>
> There are many devices which need to be served at the some critical 
> point in time
> - sound cards, video and tv grabbers, some dedicated lab cards, i/o 
>   ports etc.  Generally on the really low level this is a kernel driver 
>   which sticks to the hardware and should ``know'' how critical is to 
>   serve hw requests just in time. If we have data in a buffer programing 
>   DMA transfer is a quite quick operation but must be done at the proper 
>   moment.  So maybe we should delay a bit other io for example and just 
>   do it. But it must be done in kernel because kernel should know these 
>   critical time parameters for all devices in the system and decide 
>   which to serve and when. Maybe this is not needed for all devices but 
>   for audio/video devices it's a must. Better kernel support for these 
>   kind of devices is absolutely needed.

You're a bit mixing things:

a) we're not trying to be more compatible than OSS code in kernel, if you 
   like to do the mixing in kernel, simply write a new ALSA lowlevel 
   driver which will do it; I'm sure when the quality of your code will be 
   good,  we'll include it to the ALSA tree, but we are not going this
   way unless someone else will maintain this code
b) you're requestion to avoid scheduler participation in the audio 
   processing and yes, we have this solution already (dmix), but not in 
   kernel
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

> 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.

						Jaroslav

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