ANNOUNCE: HEAD is open for development again
tim at tjansen.de
Sat Aug 14 15:16:02 BST 2004
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.
More information about the kde-core-devel