|
Interview: Stefan Westerfeld
Stefan Westerfeld is the author of aRts (analogue
realtime synthesizer), a synth and
soundserver for Linux.
|
|
related links:
|
\ \ < 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-0.3.4.1). ... < 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 think < 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 http://www.arts-project.org 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 |
|
|