aRts vs JACK

[Eray Ozkural]

Hi Stefan!

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
> application.
>
> 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 
programmatic interface.
 - move all music related stuff as an optional thing in kdemultimedia (that 
isn't the case ATM, correct me if I'm horribly wrong)

Regards,

-- 
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