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

[Adam Tlałka]

On Thu, 3 May 2007 23:32:06 +0400
Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:
> Simple: you can't (and shouldn't) move everything to kernel. Audio
> requires pretty advanced stuff, like user-configurable resampling or
> stereo-to-surround mixing, or surround sound ajustements because
> user's audio system's setup isn't ideal. Transparent pcm
> surround-to-ac3 encoding which should work for every app that tries
> to output multichannel sound (or simply if you want to make surround
> sound out of mp3 and then pass it as ac3 over digital interface to
> surround decoder, a feature that most people with multi-channel
> system want and which audio players don't support - for a reason).
> And to load plugins which do this, there must be some library which
> loads and configures them.

Look at the fusd - you can have traditional open,close,ioctl access to
your virtual device while true processing is done by some userspace app
which then can use any library you want and the real sound device at
the end or redirect it's output through a net connection.
It's more flexible and needs no changes to apps. You have kernel
control over acces rights and descriptor cloning too which is
important too. 

> All this stuff has to be there and has to be transparent from
> application (well, maybe not completely transparent - application
> always can use different alsa devices, but at least transparent to
> dump apps which use "default" device). Do you really think it all
> belongs to kernel? AC3 encoder? Resampler options and surround
> coefficients configurable via /proc ? Alsa plugins as kernel modules?
> Brr..

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.


> Or you just want to use kernel api at any cost, even if these
> open/write/ioctls would then be routed out of kernel to some FUSE-like
> sound processing library? Kernel is pretty busy with other stuff, to
> do such stupid things. Well, right now fuse exists, because people are
> conservative and still want to use old-fashioned direct open/read/etc
> calls instead of gnome-vfs interface or something, but someday, this
> will have to change, too ;).

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.
What about shell scripts. If it is done through some kernel
virtualization any app or even script can use it easily.
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
complicated - no framework for that.

> As for people who desperately want the last approach, there always is
> aoss wrapper, which transparently replaces open/read/ioctl functions
> by alsa calls. Much better than using kernel for that. Honestly, I
> don't know why are people complaining when they can use this. Just
> never try to use oss emulation layer in kernel and everything will be
> fine.

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.
 

> If you know any other solution where you can have oss (or oss-like)
> calls and still transparently accomplish everything that people want
> from modern audio systems, then tell it. Right now every alsa hater
> around here hasn't offered a solution yet.

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

ALSA lib functions can be used in various ways. Sound output could be
achieved by using different approaches (blocking or non blocking,
memory-mapped or mixed mode or through lib callbacks) and there is no
clear documentation which way is the proper one to use and when and why.

So some kind of userspace RT daemon tied with kernel /dev interface
could be a better solution then ALSA lib. There could be ALSA hw
drivers on the bottom of course (we don't know the API ;))).

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

Regards
-- 
Adam Tlałka       mailto:atlka at pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group       - - - ~~~~~~
Computer Center, Gdańsk University of Technology, Poland
PGP public key:   finger atlka at sunrise.pg.gda.pl