ANNOUNCE: HEAD is open for development again

[Tim Jansen]

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).

> 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...

> 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...).

> 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.

bye..