ANNOUNCE: HEAD is open for development again

[Tim Jansen]

On Saturday 14 August 2004 19:19, Matthias Welwarsky wrote:
> 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. 

No, they didnt help that much, see http://kerneltrap.org/node/view/3440
(and right now many 2.6 distributions ship their kernels with preemption 
disabled, IIRC)


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

Yes, the problem is rather that it not possible for a user-space process to 
implement a kernel interface (or, alternatively, that kernel interfaces have 
been released without an abstraction layer).


> And there's absolutely nothing bad with having a service process to
> arbitrate access to a resource. This is a proven concept in Unix.

I don't doubt that it works :) But historically Unix did fewer things than it 
does today. When Unix has been designed you had, maybe, 3 services running. 
But today you have more resource types, and with an increasing number of 
resources you come to a point at which it is not a good idea to have a 
dedicated service for each resource anymore - especially as each of these 
services usually reinvents everything from configuration file formats, over 
authentication and authorization mechanisms and IPC/network protocols to  
administration frontends (including services like CUPS that come with their 
own web server).... This is a major contributor the ever increasing but 
completely unnecessary complexity of Linux and friends...


> 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 quite useful if the sound server is running on a (thin) client. It's also 
a way of getting rid of latency and a/v synchronization problems.


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

I didn't say that arts is the optimum. I just said, or at least wanted to say, 
that the optimum would be to have a single multimedia architecture (like 
GStreamer) that can be used both in applications and in the sound server (or 
whatever is responsible for mixing).

bye..