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

On Mon, 10 Jul 2006 20:39:03 -0400
Lee Revell <rlrevell@xxxxxxxxxxx> 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 general question:
Is it the proper way? How I can help improve ALSA if I just dislike its design?

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.

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

Regards
--
Adam Tlałka mailto:atlka@xxxxxxxxx ^v^ ^v^ ^v^
Computer Center, Gdańsk University of Technology, Poland
PGP public key: finger atlka@xxxxxxxxxxxxxxxxx
-
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: Cant access soundcard by several application at the same time.
    ... Only use KDE apps? ... ALSA, with dmix, solves this ... issue but not for OSS only apps and there are still some of them around. ... FreeBSD. ...
    (alt.os.linux)
  • Re: Is it time for remove (crap) ALSA from kernel tree ?
    ... If you don't then you don't need .asoundrc of ... With a properly coded ALSA app, ... Or if you want to point all apps to that device you actually could add this to ... Especially the missing proper device ...
    (Linux-Kernel)
  • Re: [Alsa-devel] OSS driver removal, 2nd round
    ... I am happy for EMU10K1 driver to be ... All the apps the user was trying also support ... ALSA natively now, ... As sound hardware gets dumber and cheaper, kernel OSS emulation will ...
    (Linux-Kernel)
  • Re: Hows the nforce4 support in Linux?
    ... As long as ALSA ... their apps to the ALSA API. ... So the endless user complaints about "wtf, esd is blocking my ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: [2.6 patch] schedule obsolete OSS drivers for removal
    ... >> I never ever did ask for any support on behalf of the ALSA bunch... ... > isolating the apps from the hardware as much as practically possible). ... recommend to use ALSA API directly with apps. ... I, at least, have never thought that the OSS _API_ would die. ...
    (Linux-Kernel)