< 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?
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 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
< 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
< jonl> no, the latest word I've heard is that it won't be
< jonl> Thanks Stefan
< stw> CU