More info about jack
stefan at space.twc.de
Sat Feb 22 21:37:48 GMT 2003
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.
However, with all the open ends of aRts and BEAST and CSL and JACK and LADSPA
and Rosegarden and ALSA and Noatun and GStreamer around, I am not currently
able to predict how eventually all of this will suddenly or slowly emergently
turn into a consistent philosophy for "professional and casual audio in open
source systems". We'll see. ;)
As long as all interested parties cooperate, I don't see much that can go
-* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
More information about the kde-multimedia