ANNOUNCE: HEAD is open for development again

[Matthias Welwarsky]

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 
latency? It does not matter if the cycles for resampling filters are executed 
in kernel or user context. Plus, you cannot utilize floating point 
arithmetics from kernel context, which makes any resampling filter apart from 
simple, low-quality linear interpolation a big hassle.

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

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

Applying pressure to Linus, (*ROTFLMAO*) or anybody else to provide this 
functionality in kernel is just not going to work, since policy on linux 
kernel development is "show me the code", like on KDE. When did you last time 
"pressure" a fellow KDE developer to implement a feature you absolutely 
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 this.
> 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 use,
> Linux.

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

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

regards,
	matthias

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze at stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040814/a0422362/attachment.sig>