[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Proposal: aRts - speed, skipping
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-04-01 22:39:34
[Download RAW message or body]

   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?

> We* need to make it simple for objects to be in their own threads.
> 
> So, there's three threads, 1: Decoder (mpeglib),  2: soundserver (with 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 threads?)  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 thought
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 threads)

> About breaking BC (if we switch to threads): The libraries can compiled 
> twice, and the soundserver always being threaded.  Or, we could always 
> compile threaded.
> 
> Any operating system that doesn't have pthreads isn't an operating system 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 threads
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 ahead.


I don't think much about "fully" threading aRts, because it wasn't designed 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 like to. You'll get
lots of locks anywhere, and deadlocks if you do the wrong thing, and so on.

The strategy should rather be to selectively thread operations that take 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.

> *We, meaning Stefan, unless he wants to write documentation ;)

Oh come on, I am getting sick of this. You saw the AIX driver just posted
here? You saw the things Jeff Tranter committed? You saw the things Nikolas
Brodu did to SmartWrappers? You saw the async multi patches by David Hamish
Harvey?

So... it is possible to extend aRts without being me. Linus also has no "how
to write a better file system in five minutes" guide in the linux kernel, and
people *do* write file systems for linux anyway. And believe me, you would not
want a file system in the linux kernel written by somebody who read a "how to
extend linux in five minutes" tutorial anyway ;)

My TODO list is more or less deterministic: I add things, and I do the things
I consider a) important and b) hard to do by somebody else.

I can add things that make sense (like a threaded OSS driver) to the TODO list
(I just did that for the threaded OSS driver thing), but it will take a
non-deterministic amount of time until they reach top priority for me, and
I start doing them ;).

So if you want it earlier, do it yourself. It's possible.

I see that some more comments/documentation at some points wouldn't hurt. But
I won't write a complete "newbie programmers guide to aRts internals", because
newbie programmers hacking on aRts internals isn't too much useful either. It
would also take A LOT of time to write, and, even worse, the more verbose your
documentation is, the more you'll have to maintain/keep consistent if
something changes.

I'll usually add comments/documentation however if you write me a mail with a
clear question that is not documentated anywhere (like "What does the
Arts::SubClass class do?").

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]