Interview: Stefan Westerfeld

Stefan Westerfeld is the author of aRts (analogue realtime synthesizer), a synth and soundserver for Linux.
aRtsd, the server, will be the sound system for the upcoming KDE2. Stefan talked to us recently from Hamburg on irc about aRtsd and its features... from a users and potential programmers point of view.

related links:
aRts project info
aRtsd C API
Hamburg Highlights

\ \  

< jonl> where were we? features of KDE2 sound?

< stw> Okay: what people will notice most is that KDE2.0 
will come with a real powerful sound server 
called artsd. It will be able to play different 
file formats, such as wav, mp3, ...

The most obvious difference to the sound 
server we had in KDE1.0 (kaudioserver) is that 
artsd can play multiple files at once. So if you are 
listening to an mp3 file, you still hear the 
sound effect when you close a window, or when a 
new mail arrives.

< jonl> right,  are there seperate apps to do the playing 
or does aRts cover that as well?

< stw> With aRts, you don't think in apps, you think in objects. 
There is a special type of object (PlayObject) that handles playing 
of files, like mp3 files. If people want a new file format, they 
implement a new PlayObject. These can be loaded dynamically.

There is kaiman - the KDE2 Media Player. Basically, it's 
just a front end to using PlayObjects, and can thus play any file 
there is a PlayObject for. Kaiman is fully themed with skins, so 
people will really love it due to the artistic touch ;-)

< jonl> heh heh 

< stw> It uses gqmpg compatible skins by the way, so there 
will be lots of skins already available when 
KDE2.0 is released

< jonl> a while ago I remember you saying something about 
ditching CORBA in favor of something else ... are 
there plans that way?

< stw> That has already happened. There is not a single line of CORBA 
code in aRts anymore. But maybe let me explain from the beginning:

< jonl> ok

< stw> CORBA is a really heavy middleware (resources), and hard to 
understand for programmers. It also doesn't know anything about 
multimedia, which made it a painful thing to work with in projects 
using it (for instance the former KOffice and aRts- ...

< jonl> yep, it's heavy

< stw> ... for KOffice, another solution was found. For aRts, I 
decided to get around this by writing a new middleware, which 
is really multimedia oriented. MCOP (multimedia communication 
protocol). The result is now used in aRts. Its really fast, really
lightweight, and integrates really well with multimedia 
streaming. It has still lots of features CORBA has, and all the 
others I've been desperately missing before ;-)

< jonl> how new is MCOP?

< stw> 
I started writing it in 10/1999, so it's seven months old right now. 
What is better with MCOP is that it thinks much more in components. 
If you look at what other people are doing, thats the way to go. 
Think of VST Plugins, or DirectSound/DirectMusic with their
COM interfaces. With the aRts/MCOP solution, 
objects you implement, like an audio effect, 
sample player, slider for the GUI or whatever 
else are just MCOP objects. They run whereever 
you need them to run. In your wave editor, in 
your game or inside your soundserver. You can plug these 
components together, and they can send streams of samples 
to each other - or streams of midi events, or maybe 
later video frames. Artsd for instance also runs 
components that are connected to each other to 
achieve its task. So people write a new effect, 
loader, or whatever else, and can run them on the 
server, if they like - a bit like X server side 
extensions like DRI or something along the lines.

< jonl> what do you think of the current "plugin" situation?

< stw> Its horrible, and I am doing my best to fix it - I 
mean: linux has - as I see it - always been weak 
in the music department. This is why I started 
aRts three years ago, and this is why I am 
working on aRts/MCOP now...

< jonl> have you heard from any other developers expressing 
an interest in using your framework?

< stw> Yes, there are quite some in the KDE department (which 
is clear, since it is in the KDE2.0 CVS). There will definitely 
be Brahms (which is a very cool sequencer). On the other hand 
I got contacted for instance from the ElectricEars author. I 
think once there are public releases of artsd, which appear 
on freshmeat and such, interest from non-KDE-people will 
increase a bit more.

< jonl> It really doesn't need to be a kde only thing I 

< jonl> If VST or VSTfree happens, how easily will that be 
integrated in aRts?

< stw> (to the kdeonly thing) I have made quite some efforts to 
make it attractive for most people. aRts is fully LGPLd, it 
uses no Qt/KDE/X11 functionality, and it is really easy to use.

< stw> (vstfree) I don't know how exactly the code looks. 
But the aRts object model will allow two 
important things: implementing objects without 
actually writing C++ code, and using objects 
without knowing their interface. That said, with 
any reasonable plugin model, using aRts plugins in that 
plugin model, and using plugins from that model in aRts 
should be not too complicated.

< jonl> Actually, I haven't heard any recent news on this so 
I'm not sure what's happening .... How about LADSPA?

< stw> There are two approaches to do a plugin interface: one 
is don't do anything but define a few functions that make up a 
plugin, and leave the programmer the work. This approach is the 
LADSPA approach, and it is good for interoperability, as supporting 
a plugin interface which just has five entry points 
is really simple. On the other hand, aRts tries to actually solve 
the more complex issues, such as inter-process-communication, 
integrated flow system, gui, scripting, midi. Its more powerful 
(but of course more complex to support than 5 functions). I think 
if LADSPA stays like it is, and if people really start using it, 
I'll make a gateway aRts<->LADSPA which allows using those 
aRts plugins without advanced features as LADSPA 
and the other way.

< jonl> Is there a guide to the API?

< stw> Thats one of the things that need work. There are a few notes 
how it works on under aRts/MCOP docs. On 
the other hand, I've written a chapter in a book (KDE-2.0 Development), 
which will be OPLd, but that is not yet released,
so not yet available on the web.

< jonl> You'll want to finish up soon (it's 1.30AM stw's time)

< stw> true ;-) ... I think we've got the most things ... 
we haven't mentioned the word realtime yet, I 
think ;-)

< jonl>  ... realtime? yes?

< stw>  I have designed aRts for really good realtime response. 
In daily life, this means: 
you can play on a midi keyboard, and get the output live synthesized via 
software synthesizer with response times as low as 10 ms or so. This is 
also extremely beneficial if you think of playing games. When playing 
pinball, you want to hear the soundeffects exactly when the thing 
happens on screen and not a while later. Or full duplex effect 
processing. Well, if you don't have KDE, simply watch out for 
the first artsd releases on freshmeat, and I'll port Quake or 
something to it, so you can see it (listen mp3s 
and shoot monsters is much more fun) ;-)

< jonl> yep, cool ... without low-latency patches I think

< stw> yes, it runs without any tweaking to your kernel.

< jonl> when do you think the first artsd will be out? KDE2?

< stw> I hope in less than a month from now - but you never know ;-)

< jonl> just a quick one - have you tried out the low 
latency stuff at all?

< stw> the kernel patches or the aRts features?

< jonl> kernel patches

< stw> I never needed them - things with aRts were always nice. 
This may depend on the fact that I have a SCSI disk, or that aRts 
usually doesn't need disk-I/O during play, or whatever. But I 
suppose most of the low-latency stuff will be integrated in 
Linux-2.4 anyway. 

< jonl> no, the latest word I've heard is that it won't be
< jonl> Thanks Stefan

< stw> CU 

 home  music  news  opinion  software  tips  email