Subject: Re: [linux-audio-dev] CORBA for Audio Apps?
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Fri May 19 2000 - 12:49:36 EEST
Hi!
On Thu, May 18, 2000 at 09:22:32PM -0500, Dustin Barlow wrote:
> I have been doing some n-tier system development for Sprint ION using
> Hitachi's C++ implementation of CORBA (TPBroker) on Sun boxes and was just
> curious to know if anyone has implemented any real time or non-real time
> audio systems using the CORBA specification?
>
> I know that both GNOME and KDE use ORBit to implement system level messaging
> between apps. I can't help wondering what the advantages/disadvantages are
> to using CORBA to implement a n-tier audio production system. CORBA allows
> developers to use C, C++, Java, Smalltalk, Ada, LISP, Python etc.. to
> develop client, middle tier and server side functionality that can be ran on
> single or multiple physical machines each of which can be running a variety
> of OSes. I would be interested in all of your opinions on the matter.
I've done that with aRts for two years or so. The latest stable aRts version
(0.3.4.1) still does so. However, I dropped it, and wrote an own middleware
similar to CORBA - called MCOP, for multiple reasons:
- CORBA is sloow
One example is this: if you implement the standard protocol, IIOP, you're
bound to lots of things, like: if you call a method, you'll pass the name (as
string) of the method, which makes it very slow, as you'll need to send the
whole string and figure it out on the receiver side.
With aRts-0.3.4.1, midi events are sent using CORBA, and as the time it takes
to invoke a method is about 1/1600 sec, you can only send 1600 midi events
per second.
==> comparing to MCOP:
MCOP is extremely fast, because it has an highly optimized protocol. It does
about 10000 invocations per second, meaning that it is 5 times as fast as
the CORBA stuff I used (I used mico, there may be faster ORBs). Much of the
time goes into IPC and task switching, so if either of these could be done
more optimal, it would benefit even more.
- CORBA doesn't know about multimedia
When you have CORBA objects, there is no way to do streaming multimedia easily.
Interfaces will contain methods and attributes, but don't know about streams.
You can somehow work around this, but you'll always have paralleling type
and interface hierarchies, which is quite broken.
You can't do something that receives an audio stream in CORBA.
==> comparing to MCOP:
You can do interfaces that contain multimedia streams in MCOP natively. So
you write
interface Synth_ADD : Arts::SynthModule {
in audio stream left, right;
out audio stream result;
};
Or, if you are dealing with byte streams:
interface Decompressor : Arts::SynthModule {
async in byte stream indata;
async out byte stream outdata;
};
The aRts/MCOP combination also will also be video streams using this. You
can of course mix this with the usual methods and attributes. It offers the
transport & scheduling of the streams locally, and remotely, so you'll not
need to care about this.
- CORBA is hard to program:
There are a lot of things at the CORBA C++ language binding, that were quite
hard to program. One thing is that CORBA doesn't use a string class, but
(char *), which will always make you wonder when to free. Another is the
object references, which are written Foo_var, and use duplicate and release,
which often confuses people using CORBA for the first time.
Another thing about CORBA which is broken is it's reference counting. It only
works locally, meaning that if you have a distributed application, you'll need
to care yourself when you may want to free your objects.
==> comparing to MCOP
MCOP uses the STL in language bindings where possible, so you'll have "string"
as string. It's references are mostly invisible to the user, so you'll not
bother about duplicate, release, and Foo_var Foo_ptr and Foo *. MCOP has
distributed reference counting which makes things easier.
..
So I'd say: if you are interested in using a middleware like CORBA for audio
stuff, which I think is a great idea, use aRts/MCOP. You'll get a superior
multimedia oriented type and object system, which has all the benefits you
may like about CORBA, but fits far better to the task than CORBA itself. Also
don't worry: it has all the features CORBA usually has, such as network
transparency, interoperability between different OSs, protocol independant
from the language (scripting languages can be bound easily),...
KDE2.0 will ship with aRts/MCOP. See also http://www.arts-project.org, look
for aRts/MCOP documentation/snapshots there (or install KDE1.90, which
contains aRts already).
Cu... Stefan
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Fri May 19 2000 - 13:50:29 EEST