BSE and KDE

[Stefan Westerfeld]

   Hi!

On Sat, Feb 22, 2003 at 01:48:07PM -0800, Neil Stevens wrote:
> On Saturday February 22, 2003 01:37, Stefan Westerfeld wrote:
> > On Fri, Feb 21, 2003 at 08:36:59AM -0800, Neil Stevens wrote:
> > > OK, looking at Jack, they say that they're low-latency and aRts isn't.
> > >  If that's true, then I think aRts (especially that capital R) is
> > > badly named. I hope Stefan is around and reading this thread to
> > > comment on this.
> >
> > Its true that aRts _currently_ is not able to keep hard realtime
> > guarantees like 3ms and down. It could be fixed, as there is code for a
> > multithreaded scheduler in aRts, but it would require rewriting all
> > calculateBlock functions of all plugins in a threadsafe way.
> >
> > So basically we come here to parts where aRts does not scale good. The
> > MCOP middleware as it is provided by the current libmcop implementation
> > is not and will not be hart RT capable. Thus, if you use MCOP, you will
> > have no latency guarantee at all, because it is running in a mainloop
> > where for instance also wave files are loaded into a cache, which could
> > take forever if you're running NFS.
> >
> > Thus it appears to be useful to have some other server (not aRts)
> > running with 3ms latency guarantee. This obviously also defeats the
> > concept of using aRts synthesis itself for low latency stuff. This is
> > why I have been working with Tim Janik on BEAST (http://beast.gtk.org)
> > recently, rather than extending the existing aRts synthesis
> > capabilities.
> 
> I have some BSE questions:
> 
> 1. Is the whole system tied to GTK, or just the BEAST UI?

As large parts of the system are currently implemented in C, and as C will
always be one language used in the implementation of BSE (which will some
day be called SFK = synthesis fusion kit), we need a library which provides
basic C functionality, such as lists and strings.

While you can do C++ without such a library, C is an unusable language if
you "just" use C and write everything else for yourself. This is why BSE/SFK
have a glib dependancy. There are no further dependancies, except for some
very minor (I think libz and at some day probably libcsl).

> 2. Is this a system you'd like to see replace aRts in KDE 4?

The honest answer is I don't know yet. I could imagine SFI replacing MCOP
or these two somehow be merged. There are many loose ends currently which need
to be tied together all at the same time ;).

> 3. Would you be able to write an aRts source compatibiltiy layer on it, 
> that would allow aRts code to work on the new system?

I might be able to. But I am not sure whether it would make sense. The problem
with compatibility layers is that you encourage using the old sources. And
that you carry the old baggage always with you.

I know that having something like Qt, which maintains a more-or-less sane
object model and way of programming that is always kept the same is extremely
helpful for development. But I am not sure whether currently the costs of
porting things like noatun to "a new technology" which would be similar but
not exactly the same as the old stuff would not be cheaper than trying to
really maintain perfect source compatibility.

> If aRts dies (I keep waiting for the day to come that you announce you've 
> given up, Stefan :-), I think any system that is source-compatible with 
> aRts would be a lot easier for KDE to use.  At least source-compatible 
> enough for Noatun, Kaboodle, Konqueror Previews, kdegames, and the other 
> arts-using KDE apps that don't have the word arts in the name.

If it is sooo beneficial, maybe you (or somebody else) could write it then?
The problem is that of course you can always put all aRts related work on
my shoulders, because I know what I am doing there ;). But in the end this
results in slowing down things too much to attain a complete implementation
of everything we need. Which then again leads to people suggesting using
something else entierly (like: use GStreamer for KDE).

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