[MPlayer-dev-eng] [patch] prefer ALSA over OSS

[Vladimir Mosgalin]

Hi Adam Tlałka!

 On 2007.05.03 at 22:44:41 +0200, Adam Tlałka wrote next:

> Look at the fusd - you can have traditional open,close,ioctl access to

I know that it's possible, and sometimes it's desired. However, when
there already is alsa library, what's the point of going back to kernel
calls which just would be routed back to that alsa library? It only
increases complexity, slowdowns and gives less features.

Of course, if no alsa existed, most safe way to introduce "sound
plugins" and other stuff would be such interface. But now, when alsa is
dominating.. why bother?

> Maybe not in kernel but in some RT process. ALSA mixing in lib works
> badly in case of swapping or big  app switching. Also doing some
> special effects processing like HRTF in sync with video needs special
> handling.

Well yeah, it could be nice, but such things exist for a long time, they
are called sound servers. Some are full of features (arts), some are
fast and provide low latency (jack), some try to incorporate best
compatibility and design decisions (pulseaudio). However, alsa with pure
in-library processing is still most popular way.

> For me it is stupid to link every app with gnome-vfs or some KDE lib.
> If someone invents another lib we will recompile our apps again.

Of course the current approach isn't best, but hey, it's called -vfs for
a reason. You just link to it, and it uses its own modules. Like you
link with alsa and user chooses which alsa plugins to use.

> And you can easily control who can do what by just UNIX rights or ACL's
> or other kernel mehanisms. In case of pure lib approach it's much more

Honestly, unix rights aren't working well for audio, with all that pam
chmod/chown stuff which gains nothing but some compatiblity so that unix
rights won't get in the way..

> Not true :(. Any app which disables LD_PRELOAD will not work. There
> are also problems with proper select emulation. And of course using
> LD_PRELOAD is a big security risc.

There is nothing nice about LD_PRELOAD. Still, it's much nicer than
problems that oss-alsa kernel emulation has. Honestly, I too think that
it would be nice if oss emulation in kernel would somehow be routed out
of kernel to alsa-lib, but we all understand why it wasn't done yet,
this approach is very complex and should be carefully designed. Also I'm
not sure what is better, fusd-like approach or preload stuff, they all
are pretty broken as permanent solutions...

> Modern OSS kernel API is good enough IMHO and documented too.

I gave an example: I have usb soundcard, I can't use oss driver in
mplayer. Alsa "just works". There is no way to "fix" oss layer. Oss is
provided through alsa emulation, of course, I won't install 4front
drivers just to get mplayer's oss output working.

> > don't honestly believe that anyone would want that. The thing is,
> > modern audio is no simpler and just as well requires library
> > approach, it's the least problematic solution.
> 
> It's very problematic and completly non-Unix way.

Programs don't access video cards for 3d acceleration directly, they use
libraries; good programs don't read terminfo themselves, they use
ncurses library which works with underlying hardware for them; and so
on. Directly accessing hardware is always possible, but usually it only
leads to problems. The same with audio. What is non-unix about that?
With alsa, you always can access hardware device directly if you know
what to do with it.. if you don't - it's your problem, you should've
used library anyway.

-- 

Vladimir