ANNOUNCE: HEAD is open for development again

[Matthias Welwarsky]

On Saturday, 14. August 2004 16:16, Tim Jansen wrote:
> On Saturday 14 August 2004 14:37, Matthias Welwarsky wrote:
> > 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.
>
> The context switches are the problem, especially for low-latencies (which
> need smaller frame sizes and thus more context-switches).

To be precise, the problem is scheduling latency, not frequency of context 
switches. This used to be a problem with linux before the preemptive kernel, 
the O(1) scheduler, etc. Not a valid argument to put mixing into the kernel 
any more. You can get pretty far with multithreading and realtime scheduling.

> > The kernel should not be bloated with application specific demands. It is
> > ultimately an abstraction layer that provides nothing but hardware
> > access.
>
> Is this your main argument or just a side-note? In the first case, the
> question would be "assuming that the user experience suffers from this,
> should a kernel provide a worse user experience in order to have a clean
> architecture?" You could let the users decide, but...

In order to keep an OS kernel stable and architecturally clean, yes. The 
problem is not "the kernel", it is rather the fact that there has never, ever 
been something like a true multimedia infrastructure in linux. People are 
used to bang the kernel interfaces directly, ever since OSS was invented. So 
about the only agreed-upon interface is OSS (and ALSA, well, sort of), and 
people tend to force functionality into it.

> > Also, what about network transparency? Following your reasoning, this
> > also belongs in kernel so that it "just works"?
>
> IMHO a kernel should at least provide the hooks, but the problem with
> general network transparency in the kernel is its bad design (or more
> precisely, Unix just never has been designed for that and the ugly ioctl()
> hacks are great at preventing any attempt, which is why the typical Linux
> installation has at least 4 special purpose servers for sharing
> devices...).

This has absolutely nothing to do with bad design. You have to draw a border 
somewhere, or you will never be able to provide a stable framework. And 
there's absolutely nothing bad with having a service process to arbitrate 
access to a resource. This is a proven concept in Unix.

> > 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.
>
> The opposite is also bloat: then you need two different architectures for
> mixing, resampling etc. You also need codecs for network transparency with
> optimal quality. Duplicating functionality won't make it any simpler.

No you don't. You're mixing "architecture" and "applications". Why shouldn't 
your "application" use the same codec "architecture" that the soudserver 
"application" uses? 

But how useful is a soundserver that reads, decodes and outputs MP3 files all 
in one go, or directly streams media from a server? Look at noatun. It's 
nothing but an arts frontend, and if you want it to do something that arts 
does not support (hint: shoutcast title info), you have to either force it 
into arts, causing bloat there, or you have to duplicate functionality, 
causing bloat in noatun. It's bad either way, but causing bloat in a central 
component is worse, because a failure _there_ generates much more angry 
users.

So I reason that there has to be an end to features, which is true for the 
linux kernel, and also true for a sound server.

-- 
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/c36f28a7/attachment.sig>