Re: [linux-audio-dev] acid, linux

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] acid, linux
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: ke joulu  01 1999 - 20:18:30 EST


   Hi!

On Wed, Dec 01, 1999 at 05:56:56PM +0100, MOULET Xavier CNET/DMR/ISS wrote:
> [...]
>
> Thus, I am waiting eagerly of an implementation of the API discussions (or
> is there one ?), and of course, of an engine.
>
> Is there already one or many good engines fundations for such a thing ?
> Would Quasimodo (without the interface) do the job or is it too Csound
> oriented ?
> Raw Esd ? THE API (mucows (?)), aRts ? xmms ?

I can tell you what aRts is doing right now.

The idea I have is moving away from CORBA towards a lighter consistent
object model which spreads throughout aRts. The thing will be called
MCOP, which expands to multimedia communication protocol. But keep in
mind that it cares about communcation and object model (the things that
were handled by CORBA before). One will write things like

interface Synth_ADD {
  in audio stream signal1, signal2;
  out audio stream result;
};

in an idl file, and it will generate C++ skeleton classes, which you
only need to implement. For Synth_ADD, this could look somthing along
the lines:

void SynthAdd_impl::calculateBlock(unsigned long cycles)
{
    float *end = result + cycles;
         
        while(result != end) *result++ = *signal1++ + *signal2++;
}

that's about all you need to write. By the way, you could also have
something like

interface BinaryOperation {
  in audio stream signal1, signal2;
  out audio stream result;
};

interface Synth_ADD : BinaryOperation {
  //
};

which means you get the wonders of polymorphism and inheritance in your
plugin system.

The component communication will be handled transparently to the programmer,
and also whether it is in the same process space (linked as library), or in
another thread, or in another process or on a computer somewhere on the
network shall be transparent.

So using aRts as library should finally be possible for those who want
to do that. (This is really important for wave editors for instance). Also,
people will not any longer need to install mico to use aRts. Another
advantage is that the overhead is much much less.

Perhaps other people who are still considering whether they want to do
something similar could also join in. Basically, writing a middleware
like MCOP is a lot of work. It is more or less as complete as CORBA (at
least the relevant parts I used) in it's current development stadium,
though not everything works fine yet, but it supports

- remote method invocations
- inheritance
- multiple inheritance
- using components transparently as libs or remote
- do marshalling
- define own datatypes (e.g. structs and such) in the idl file, such as
  struct MidiEvent or struct FFTPacket
- C++ language binding (if you want - write a C implementation of MCOP,
  at least apps/plugins will be able to communicate properly then)

from my speed tests, it wins factor three against mico for synchronous
invocations, but the slowness is obtained by using a TCP transport, rewriting
that to sharedmem should give another major boost. Also, the real gain is
that you can support streaming, QoS, event transport, etc by your
communication layer, which was impossible to do with CORBA before.

KDE2 will use aRts as multimedia framework, which also means the sound
server that will be running for the desktop will be implemented on top
of that. It will also not necessarily remain an audio-only thing, video
for instance would also be great - but that has some time.

The engine is partially ported from CORBA, but it currently can't do more
than a beep (but at least that: fully modular) - also the plugins aren't
ported, and some infrastructure is still completely missing (Qt GUI stuff).

So the dependancies aRts has are reduced to: C++ with STL (no Qt, no Mico,
no KDE, no X11, if you really want not even Unix are required).

The code is available from the KDE CVS (kdemultimedia/arts), which you also
can get anonymously if you like via CVSup. It is still in its experimental
phase, but I'll port over all aRts infrastructure to MCOP in the next time,
though that may take a while.

   Cu... Stefan

PS: Please - everybody who is now writing something similar - step back a
second and think of you couldn't join aRts. What is missing?

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST