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

Nicolas George nicolas.george at ens.fr
Thu May 3 20:30:44 CEST 2007


Le quartidi 14 floréal, an CCXV, Rich Felker a écrit :
> Yes, i.e. they're actively malicious against developers and users.

That is not what I said.

> It's not cleaner, it's much worse.

No. For one, it is type safe.

>				     One way in which it's worse is
> fundamental; you cannot pass/inherit ALSA device contexts across
> exec() or via sending file descriptors over unix sockets or fifos;
> doing this with OSS is trivial because the device model fits naturally
> with unix device/file/permission semantics.

Well, that is a point, although I never felt the need to do that.

> These things don't belong in the hardware abstraction at all. They
> belong in sound servers, filter APIs, etc. -- things which some users
> may OPTIONALLY choose to use, while others who do not need them
> ignore.

In principle, you would be right.

In reality, as a user, I would rather have as few different libraries /
filters / sound servers, because each time I want to configure something, I
have to do so for each one. And if the kernel exports a public API, you can
be sure that some developer or some other (and probably both, in fact) will
feel compelled to reinvent the wheel, and will do it triangular with
absolutely no way to fit any tire. And according to Murphy's law, it will
probably be in the one application where I need to do something subtle with
the sound output.

> This is not a plus. It means your application will behave erratically
> and have horrible performance or low quality in unpredictable ways.

That means that the user can chose to risk it if he wants. Or not. He
choses.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070503/9d54b451/attachment.pgp>


More information about the MPlayer-dev-eng mailing list