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

List:       kde-multimedia
Subject:    Re: Proposal: aRts - speed, skipping
From:       Charles Samuels <charles () kde ! org>
Date:       2001-04-01 23:29:03
[Download RAW message or body]

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 
versions of it around, when this kind of stuff _should_ be threaded.  It's 
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 (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)
But mpeglib having its own thread, where the output plugin doesn't sort of 
defeats the purpose.  Isn't it all backwards?  There can be as many slowdowns 
as we want in the "beginning" as long as the output keeps a good buffer.  Am 
I not right?


>
> > 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 would, however, I don't get skipping :)  But I'll talk to rik hemsley (who 
seems to be having problems).

However, why thread it if that won't work on FreeBSD (with the pthread libc 
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 
decoder.  Speaking of which, he just got a patch for linuxPPC, which 
basically makes aRts useful :)

>
>
> 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.
I think now would be a good time to start planning for KDE 3 and big 
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 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?
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 
almost competent, the biggest reason I remain unwilling to participate in 
arts itself is just because I don't know where anything is.  I think if you 
provided a document on at least where everything starts and ends, and common 
tasks like creating a client, and server-side object, it'd be very helpful to 
all of us.

[Snip] less email, more food ;)

-charles

-- 
Charles Samuels <charles@kde.org>
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

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