MAS in KDE

[Stefan Westerfeld]

   Hi!

As I had mentioned previously on this list, Tim Janik and me were in
Copenhagen this weekend to discuss sound and interoperability issues with
Leon Shiman, head of the MAS development team. To sum up the meeting, the
following things can be said:

(a) MAS itself (see also http://www.mediaapplicationserver.net)

MAS is a media server developed with a lot of experience after an intensive
design phase from developers with a lot of X and audio experience. It goes
beyond a pure sound server but also does synchronization of different media
types. As such it has the capability of providing timing for arbitary
media streams on arbitary machines. Thus, not only sound streams but also
midi and video streams can be synchronized.

An important basic design feature MAS has is that it uses a peer-to-peer
approach when it comes to getting multiple hosts synchronized. With one MAS
server per host, all devices of all hosts are accessible from all hosts. It
doesn't matter whether we're talking of windows hosts or unix hosts here.

(b) aRts and MAS

While MAS does things aRts doesn't (pervasive timing, peer-to-peer networking),
aRts does things that MAS doesn't (managed audio routing, management of
multiple clients, providing a rich high level API, midi). We have decided to
cooperate more intensely in the future to

 - get the right things done in the right place (MAS should concentrate on
   what is necessary on the lowest level, whereas aRts should support MAS
   as the lowest level)
 - provide seamingless interoperability
 - share the experience of both projects

(c) CSL and MAS

As MAS currently does not provide a frontend library like CSL, something like
this will be needed. We toyed with the idea to use CSL as a means of making
those apps that do not need any special sound or media server functionality
MAS-aware, as by making applications CSL-aware you can achieve a lot more than
by simply making them MAS-aware, because they also will be able to use the
other CSL backends. Thus whenever you write a driver for some free software
application and have the choice between

 - adding MAS support
 - adding CSL support

CSL support sounds more attractive, because by adding CSL support, you also
get MAS support once you have a MAS driver in CSL, which also implies aRts
and JACK and whatever-else support, once the drivers for CSL have been written.

(d) KDE, Gnome, CSL and MAS

To ensure interoperability between these (and further developments in the
area), one strategy that looked very promising is to use CSL as common
interoperbility standard between KDE and Gnome. This will not only instantly
make KDE be able to use MAS and Gnome able to use MAS. The same would happen
for any other sound / media server which could support CSL. In that way, the
way of promoting sound server agnostic behaviour in desktop environments
appeared to us as good solution.

(e) Further discussion and further plans

If financing can be ensured, we plan another meeting to get the CSL API and
MAS API discussed and reviewed together, to then decide on the direction to
work on. If not, that discussion needs to take place on IRC/Mailing Lists/...

While we got quite some idea of strategical and organizational issues and the
goals of what we want to do, the technical issues (like APIs, implementation
details, source code quality issues, ...) still need to be sorted out, and
thoroughly discussed / reviewed.

We hope to thereby solve the interoperability discussed in the previous
section within this month.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-