On Sunday 01 April 2001 03:39 pm, Stefan Westerfeld wrote: > Hi! > > On Sat, Mar 31, 2001 at 01:39:45PM -0800, Charles Samuels wrote: > > aRts skips a lot, aRts doesn't work on most platforms. > > > > And both of these problems have one fix. Well, 1.5.. > > > > We* need to completely eliminate the non-threaded version of arts. > > Why? Well, I think it's just because it doesn't make any sense to keep two=20 versions of it around, when this kind of stuff _should_ be threaded. It'= s=20 2001 :) This is probably subject to argument > > > We* need to make it simple for objects to be in their own threads. > > > > So, there's three threads, 1: Decoder (mpeglib), 2: soundserver (wit= h > > all the sound effect processors), 3: output. > > > > Yes, yes, output needs to be in its own thread. Even xmms (and I don= 't > > want to use xmms in any discussion ;) is 5 threads (1 process+4 threa= ds?) > > This may also mean a sync problem between visualization and audio. = Oh > > well :) By putting multiple buffers in the scope objects, that can be > > limited. > > It's no problem to write a threaded OSS output driver for aRts - I thou= ght > about that, then you'll pretty much have > > a) XMMS behaviour (which is supported by most soundcards, maybe better = than > fragments + select which aRts currently uses) > > b) the three threads you talk about (mpeglib already uses its own threa= ds) But mpeglib having its own thread, where the output plugin doesn't sort o= f=20 defeats the purpose. Isn't it all backwards? There can be as many slowd= owns=20 as we want in the "beginning" as long as the output keeps a good buffer. = Am=20 I not right? > > > About breaking BC (if we switch to threads): The libraries can compil= ed > > twice, and the soundserver always being threaded. Or, we could alway= s > > compile threaded. > > > > Any operating system that doesn't have pthreads isn't an operating sy= stem > > at all. We can all agree on the futility of supporting them :) > > You'll not break BC. You can implement threaded stuff in aRts using the > Arts::Thread class (thats what libmcop-mt does), and if you have no thr= eads > you'll need to have fallback code. In the case of a threaded OSS driver > thats easy because we already have a non-threaded OSS driver available,= so > you'll simply offer the threaded OSS thing as alternative. Please go ah= ead. I would, however, I don't get skipping :) But I'll talk to rik hemsley (= who=20 seems to be having problems). However, why thread it if that won't work on FreeBSD (with the pthread li= bc=20 issues). I don't know about this problem yet, but will it be fixed? And = when? Also, Kevin Puetz (for LinuxPPC) says he's currently working on an mpg123= =20 decoder. Speaking of which, he just got a patch for linuxPPC, which=20 basically makes aRts useful :) > > > I don't think much about "fully" threading aRts, because it wasn't desi= gned > to be fully threaded, and constructs like smartwrappers, reference > counting, shared classes (like the dispatcher), the main loop and so on > will break if you allow all objects to work in any thread they would li= ke > to. You'll get lots of locks anywhere, and deadlocks if you do the wron= g > thing, and so on. > > The strategy should rather be to selectively thread operations that tak= e > long (like loading a file or doing a DNS lookup), and keeping the aRts = core > non- threaded as it is. All other things are KDE3.0 code, thats the > earliest point point in time I would touch some big change like this. I think now would be a good time to start planning for KDE 3 and big=20 binary-incompatibility day > > > *We, meaning Stefan, unless he wants to write documentation ;) > > Oh come on, I am getting sick of this. You saw the AIX driver just post= ed > here? You saw the things Jeff Tranter committed? You saw the things Nik= olas > Brodu did to SmartWrappers? You saw the async multi patches by David Ha= mish > Harvey? Now I know how you are when you're pissed off :) Ok, well, first, I apologize, but secondly, I'de like to say that while I= 'm=20 almost competent, the biggest reason I remain unwilling to participate in= =20 arts itself is just because I don't know where anything is. I think if y= ou=20 provided a document on at least where everything starts and ends, and com= mon=20 tasks like creating a client, and server-side object, it'd be very helpfu= l to=20 all of us. [Snip] less email, more food ;) -charles --=20 Charles Samuels K Desktop Environment "The people. Could you patent the sun?" -- Jonas E. Salk, when asked who owned the patent on his polio vaccine. _______________________________________________ Kde-multimedia mailing list Kde-multimedia@master.kde.org http://master.kde.org/mailman/listinfo/kde-multimedia