MAS in KDE

[Mike Hearn]

> GStreamer is not a sound server. It is a in-process library that allows you to 
> process media. It is useful if you want, for example, play or record a file. 
> But it would less useful for a application that does everything itself, like 
> many games do.

Right, I'm aware of that. Still, from the perspective of GNOME,
GStreamer makes the sound server chosen irrelevant, and I suspect that
the situation will be the same for KDE eventually.

> 
> > I'm sure I've oversimplified the situation massively
> 
> I think so :)

Well, thanks for explaining all this.

> The ideal sound server would:
> - be able to mix the sound of several applications (the basic sound server 
> functionality)
> - offer the low-latency and other features of jack
> - be able to send, forward and receive audio and video over the network
> - be able to decode and encode the network audio and video itself, because 
> only this can guarantee you optimal performance over a network (IMHO arts' 
> way of doing everything in a single process is the right one, arts just lacks 
> too many features)
> 

OK, so the reason that we can't just standardise on Jack and make
everybody mostly happy is that it's not network transparent? About the
last point, does being able to decode and encode network audio/video
imply having the media framework *inside* the sound server a la aRts, or
would writing say an ogg filter for the network transparency jack plugin
be enough? 

If the idea is you can stream audio before it's decompressed, then maybe
a codec on the networking side is good enough, after all if you're using
a network performance isn't critical anyway, and not everything played
via the media framework would be compressed anyway. Hmmm.

> Unless someone comes up with a server that has all those features, KDE has two 
> choices:
> - agree on one of the existing sound servers, use all of its capabilities and 
> live without the rest; maybe in the hope (but without a guarantee) that it 
> will get the rest later
> - use CSL and have only the most basic features, until someone comes up with a 
> sound server that fulfills all requirements

So basically the blocking issue is the lack of a sound server that is
good enough for everybody?

thanks -mike