MAS in KDE

[mike at theoretic.com]

> CSL is a wrapper around a wrapper (aRts or MAS or SDL) to the sound
> driver.
> 
> CSL is in C, so KDE will need yet another wrapper to wrap it.  (On the
> other hand if you wrote it in C++, maybe you could easily export a C
> API at the same time)
> 
> Isn't this too much?  Aren't any time benefits with MAS going to get
> killed with all these wrappers?  Is it really that hard to pick one
> good future media/audio server strategy and commit to it? :-)

Thanks for forwarding this btw, I've been following the discussion you guys
have been having lately on MARC...

One thing I've been wondering is what the benefits of MAS are over Jack,
seeing as there seems to be quite a bit of duplication between gstreamer,
aRts, and MAS (they all have a "streaming media" system iirc). It seems
Jack would be a much easier sell than any other sound server, simply
because it's been designed by the professional linux audio community, and
focusses only on playing sound in a low latency way.

> 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? There's a higher-level API
wrapper around it called monkey-media, which in fact can delegate to
various other backends as well like Xine, which is useful for playing MP3s
and various other simple tasks. GStreamer isn't Linux specific if that's
what you're thinking.

> For ensuring interoperability between both desktops in the future, I sat
> down with Tim Janik (Gtk core developer) quite a while ago, and discussed
> how and why we should design an interoperable implementation for sound
I/O.
> Thus, we wrote the paper and the implementation you'll find on the CSL
> pages.

That's the other thing I don't quite understand - what does CSL get us that
standardising on a sound server does not? Or is the idea that we can't
standardise on a sound server, so CSL sits above that layer?

> In any case, I'd like to ensure that whatever KDE chooses has the
potential
> to get widely accepted in the free software community as "a standard audio
> API", so that the optimal code-reuse and interoperability can be
guaranteed
> in the future.

This is definately a good goal, but I think it's easy to end up with a
wrapper API for everything, when at the end of the day it might simply be
easier to say, let's use for Linux:

ALSA
Jack
Multimedia API (ie gst, xine, arts)
Simple wrapper for going boing at approximately the right time sort of API

Then for other forms of UNIX the multimedia API can deal with alternative
implementations (for instance maybe on other forms of unix you don't need a
sound server because it does mixing/resampling in kernel).

The pivot point clearly there is Jack, if KDE decides not to use GStreamer
(which imho would be a crying shame), KDE, GNOME, 3rd party and pro audio
apps can all co-exist happily with each other.

I'm sure I've oversimplified the situation massively, any insights would be
appreciated.

thanks -mike

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .