--Boundary-02=_gegHB2t4ILzWk+G
Content-Type: text/plain;
  charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 14 August 2004 01:35, Charles Samuels wrote:
> On Friday 13 August 2004 4:26 pm, Michael Nottebrock wrote:
> > On Friday 13 August 2004 23:37, Charles Samuels wrote:
> > > Let me try again:
> > > Ideally 90% of our users (Linux) would get their audio mixed by the
> > > kernel (so they'd get the lower cpu usage, less latency, and
> > > compatibility with other apps).  The other 10% would get some stupid
> > > soundserver to do the mixing.
> >
> > I'd much rather like 100% of the users getting something that won't
> > effectively make non-Linux unsupported AND does not suck. I'm not sure
> > 100% of the Linux users would like KDE suddenly being dependent on ALSA=
's
> > api/abi-'stability' either.
>
> Sorry Michael, if the kernel doesn't do the mixing, it's going to suck for
> 100% of our users. This has been proven time and time again by all the
> mixers that have been attempted. I want something that works well for
> almost everyone, and if the other 10% want their system work as well as it
> does on Linux, then they can fix their kernels to support mixing.

Why do you think that mixing in kernel consumes less cpu, produces less=20
latency? It does not matter if the cycles for resampling filters are execut=
ed=20
in kernel or user context. Plus, you cannot utilize floating point=20
arithmetics from kernel context, which makes any resampling filter apart fr=
om=20
simple, low-quality linear interpolation a big hassle.

The kernel should not be bloated with application specific demands. It is=20
ultimately an abstraction layer that provides nothing but hardware access.=
=20
Mixing audio or video streams is absolutely out of scope unless you have=20
hardware that supports it.

Also, what about network transparency? Following your reasoning, this also=
=20
belongs in kernel so that it "just works"?

Applying pressure to Linus, (*ROTFLMAO*) or anybody else to provide this=20
functionality in kernel is just not going to work, since policy on linux=20
kernel development is "show me the code", like on KDE. When did you last ti=
me=20
"pressure" a fellow KDE developer to implement a feature you absolutely=20
wanted but were to lazy to implement yourself? Did it work?

> We will provide a mixer, but it sucks far too much for something like thi=
s.
> Our users *hate* soundservers.  I *hate* soundservers. I want them to go
> away!  I particularly most want them to be unnecessary on the kernel I us=
e,
> Linux.

There's nothing, _NOTHING_ wrong with sound servers. The only thing wrong=20
about them is bloat, like media codec plugins running inside the sound serv=
er=20
process. That's the main problem with arts. It's way to complex and=20
feature-rich. Make it lean, mean and simple to use and users will not even=
=20
notice its there.=20

About the only thing that bugs users about sound servers is that they might=
=20
access the sound hardware exclusively. That is, they cannot run xmms and=20
don't see what causes the problem, as no other "sound" applications are=20
visible on the screen. If you make the sound server behave properly and=20
release the sound device if no client application is attached, you have=20
solved about 90% of the problem.

regards,
	matthias

=2D-=20
Matthias Welwarsky
=46achschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_gegHB2t4ILzWk+G
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBHgegANO+fpRuZ2IRAqGBAJ9IQ/W/djc1qYLAjCjBM3rluoUrpwCcCr/S
L1mFjmwrw/yrYHTRTWEjOds=
=IOdl
-----END PGP SIGNATURE-----

--Boundary-02=_gegHB2t4ILzWk+G--