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

[Zsolt Barat]

Reimar Döffinger schrieb:
> Hello,
> On Thu, May 03, 2007 at 07:50:53PM +0200, Zsolt Barat wrote:
> [...]
>> you are suporting a stonaged driver model, which was good for simple
>> audio devices but can't catch up with soundsystems we have nowadays, at
>> least it didn't. it is like saying: "let's go back to a drivermodel for
>> monochrome displays, because it's so simple and fits so well into the
>> unix philosophy of device access"
> 
> Well, what exactly is it missing (from an API standpoint, not
> implementation), and more importantly what of that could not have been
> adding by improving it e.g. adding a few ioctls?
as we are criticizing the ALSA API right now. it is not about what is
missing in OSS, it is about whats the purpose of ALSA. the purpose of
ALSA is to present the developer an easy to use API in the common way,
means access to functions of the sounddevice by functions not by
filedescriptors.

And yes there are helper functions, which lives in the library. What
should be wrong with the approach to centralize some helperfunctions in
one lib, like resampling, routing etc. it is codeduplication to do this
in every app seperatly.
and at least ALSA-API is not complicated. when you understand the
fundamental basics, the learning curve is pretty low. for me openegl-api
or xorg-api is much more complicated and bloated than the alsa one.
It is well documented too. it has a nice doxygen-doc for each function.
who complaints about spare userdocumentation can contribute. there is an
alsawiki for years. it is an opensource project like mplayer.

>> At least it is true that there will be no way back OSS, and OSS will be
>> removed from the kernel soon (or it is allready?). Using the
>> oss-emulation-layer of ALSA just for protest is really braindead.
> 
> Until recently it did work better. And it is also true that MPlayer's
> ALSA driver was highly unstable, and it required about a year, many
> fixes in ALSA itself and a ALSA developer working on it to the level
> where it is working better than OSS.
no offense against alsa-developers working for mplayer, but that an
"alsa-dev" reworked ao_alsa is simply a myth. look at the changelogs
yourself and you will see that not so much happend there since the
initial design was finished. the biggest commits were removing of mmap
and the noblock part. thats code deletion. this parts were never active
by default, and more a personal playground. i would have agreed, since
it's better for maintenance. the others are mostly bugfixes for S/P-DIF,
AES. so at the end nothing dramatic happend in the core-part.
ALSA itself improved a lot thats true. but this is also because being
the default in most distros nowadays. you will not help the alsa-project
by only using the OSS-emulation layer.

> Maybe you really never had any problems, but I remember times where you
> had to tell someone on IRC to use -srate 44100 or -srate 48000 to make
> ALSA work almost daily, if you missed that completely I think you never
> had to do with many ALSA users (or they were all playing content with
> nice 44100 samplerate on a soundcard that had exceptional drivers and
> supported all samplerates anyway).
> 
yes there were problems, as with any new interface. but, well, i don't
understand your point here. sometimes you argue that users should rtf
and care about their enviroment and now you want an automagic system
which works out of the box. i really don't mind to put srate=48000 into
my mplayer.config or change .asoundrc.

best

zsolt