MAS in KDE

[Stefan Westerfeld]

   Hi!

(I'll add xdg-list to the CC, because some of the things I've put into
 this mail might be worthwile discussing there).

On Tue, Mar 04, 2003 at 07:07:26PM -0500, Navindra Umanee wrote:
> Stefan Westerfeld <stefan at space.twc.de> wrote:
> > 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
> 
> 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? :-)

The problem is that I am very very often getting questions like

"Look, I don't care about whether you wrote aRts or not, but all I want to
 do is really to only output/record the _raw_ data, how should I do this?"

Often, I don't really know what to answer on that question. There are a few
answers:

(1) use libartskde: this is a problem, because libartskde currently only
  implements a KAudioRecordStream, and I don't like its implementation either ;
  its simply not good enough to recommend it

(2) use libartsc: this is what in fact lots of users do ; the problem with
  this is that it suffers from some basic problems
   - its not threadsafe (thus you can't record and play streams in seperate
     threads)
   - its not a C++ API

(3) use the aRts API directly: this is what some people do, but it often ends
  up in suboptimal applications, because they often misuse the API ; they
  don't know how it works, and what they should do with it ; finally, the
  middleware based API was designed to solve complex tasks ; if you solve a
  simple task with it (such as playing a sound stream), you will run into
  trouble

Thus I need to solve this problem. That is, I need to provide an API for users
that they can use for playing and recording a sound stream. Ideally, this API
would be a "full KDE" API, that is, one that uses QObject, signals & slots
and all other things that KDE developers are used to.

So I'd say it would be beneficial for KDE3.2 to ship with such a C++ API. Lets
call it KDE Sound Layer (KSL) to have a name.

Now is the question how this API should be implemented. We know that aRts is
not the only sound server around, and that maybe sometime in the future, it
will make sense to switch from aRts to something else (i.e. MAS). Right now,
however (until KDE4), we need to keep aRts around for backward compatibility.

Thus, I'd like to have an implementation which does not depend on aRts, but
can use other things to output sound as well.

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.

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.

Now that I publically discuss this, an alternative implementation which we
might use, PortAudio (http://www.portaudio.com) has also been proposed as
Implementation which might fulfill the same goals CSL was designed for.

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.

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