MAS in KDE

[Tim Jansen]

On Wednesday 05 March 2003 10:46, mike at theoretic.com wrote:
> > GNOME, by the way is in the same situation: they might want to provide a
> > portable way to their users to output sound, but they currently don't.
> I thought this is what GStreamer was for? 

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.


> Or is the idea that we can't standardise on a sound server, so CSL sits
> above that layer?

Exactly. 


> This is definately a good goal, but I think it's easy to end up with a
> wrapper API for everything
> Multimedia API (ie gst, xine, arts)

You cannot write a common wrapper for GStreamer and Arts (or MAS) without 
losing 95% of their functionality.


> I'm sure I've oversimplified the situation massively

I think so :)
It would be easy if all media frameworks would only be used for playback, and 
all sound servers would be limited to mixing the audio output of several 
applications. But all the systems that you mentioned have their own 
advantages, and they are there for a reason. If you want to support them all 
you are left with the least common denominator. You could as well use ESD...

And that's the whole sound server problem IMHO. The JACK guys are so excited 
about their ability to write high-end audio applications that they seem to 
ignore that their design does not help for audio over the network. MAS is 
extremely well at this, but does not provide the capabilities that the audio 
guys need. MAS and Arts both include a half-baked media framework that can't 
compete with complete frameworks like GStreamer and makes any decision more 
difficult because there will always be code duplication. And then, of course, 
there is also a lot of existing KDE code that must keep running.

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)


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

bye...