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) 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 _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia