aRts vs JACK
exa at ttnet.net.tr
Tue Feb 25 02:11:45 GMT 2003
On Saturday 22 February 2003 23:59, Stefan Westerfeld wrote:
> If you go for low low low latency, then a context switch more or less can
> make a difference. This is why having two applications involved in music
> production (a sound server and a synthesizer) is worse than having only one
> If you have ten synthesizers, and route audio back and forth between them,
> ten applications are the much worse design (IPC costs!) than one
> application. This is why I choose the design initially.
My point exactly!
> Fatally, by moving it into KDE and lots of people adding lots of things to
> it, the low latency requirement can't be fulfilled by aRts-as-it-is-now any
> longer. Which is why although I think the design is good, the
> implementation should be redone or partially redone, especially for music
> production purposes.
Can it be done so as to use a light-weight transfer protocol than a CORBA
implementation? i think the L4 and Hurd guys had such things working but I
can't really be sure what's going on there....
If we do the following all the problems mentioned can be solved:
- make the sound server a fast thing w/ low latency. the software should have
the ability to use hardware mixers, etc. in application space when possible
but if so desired still retain network transparency. the issue is not having
to use a slow IP transport with an ill-defined latency specification of a
broker, the real abstraction required is not at that level but at the
- move all music related stuff as an optional thing in kdemultimedia (that
isn't the case ATM, correct me if I'm horribly wrong)
Eray Ozkural (exa) <erayo at cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
More information about the kde-multimedia