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

List:       kde-multimedia
Subject:    Re: Patch for Kaiman
From:       Antonio Larrosa <antonio () larrosa ! org>
Date:       2000-08-26 12:47:49
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    Hi!
> 

Hello,

> On Thu, Aug 24, 2000 at 06:34:34PM +0200, Antonio Larrosa wrote:
> > I've noticed that aRts crashes some times when playing "corrupted"(?)
> > files and this makes Kaiman crash too.
> >
> > The attached patch makes Kaiman "feel" more stable, as it detects when
> > aRts has crashed, try to run it again and re-connect to it. Also, if
> > aRts is not running when starting Kaiman, it starts it instead of
> > asking the user to do it by himself.
> 
> Yes, I think this is a good idea (though of course debugging all
> artsd crashes is also a good idea ;).
> 

Hehe :) I knew you were going to tell me that :)
But I don't have the time currently for debugging it.

> > The second problem is that I cannot use -d when running aRts from Kaiman
> > (although it works when running aRts from a Konsole).
> 
> I can't reproduce this here. It works fine when kaiman starts artsd as well.
> I uncommented the commented-out full duplex lines, and tested it with
> artsbuilder, some full duplex test struct and a microphone, and the only
> thing you need to do when you killall artsd (which kaiman promptly restarts)
> is restarting the execution in artsbuilder as well.
> 
> I noticed some "timeout occured" messages, but they are present in either
> way of starting artsd and obviously no problem, they are probably occuring
> now because we changed the packet size in "confortable" mode recently.
> 

You're right, the full duplex thing seems to be broken
independently(sp?) of the way artsd is started :)

I've tried 
artsd -d -F 3 -S 512
artsd -d -F 3 -S 4096

and in both cases I get the "timeout occured" messages and artsd tries
to consume 100% of my CPU .

> > The third problem is that there's a race condition when starting aRts.
> > Anyway, I'm not very worried about this, as in the worst case of the
> > race condition we get the current behaviour and in the best case, we
> > get a much better behaviour.
> 
> This can be fixed easily by adding a retry cycle to after the "system"
> command which could look like the one in knotify (see kdelibs/arts/knotify).
> 

I think 8 seconds on a startup sequence to stop trying to connect to 
the server is fine. But 8 seconds to get an error messagebox since
starting an application or clicking on play is too much. I'll
probably leave it as 3 seconds, is that ok ?

> There are three more issues I observed:
> 
>  * code duplication
> 
> Currently, you have code from kcmarts, which means that once you change
> kcmarts, you also need to change kaiman, which is not exactly maintainable,
> especially if more apps start using a technique like this.
> 

Yes, I thought that adding that to arts would be nicer, but didn't
have the mood to hack on aRts. Feel free to move it to an arts library.

>  * starting on the wrong computer
> 
> If you are running artsd network transparent, then eventually the restart
> will happen on the wrong machine. Which can't be exactly solved for KDE2.0
> I guess, and is not so bad, because you'll run into trouble with a network
> transparent kaiman anyway.
>

Good point, I didn't thought of it. But I don't think it's that
important. The only problem is with video files, and video files are
anyway a problem when running on a network as you said.

>  * better use .error() to detect errors
> 
> To see if the MCOP invocation
> 
>   foo.doSomething();
> 
> went all-right (or didn't work, since the server holding the foo-Object has
> crashed) is checking foo.error() afterwards. I attached a patch against your
> patch to show how it should be done in the .play() method.
>

Thanks, I didn't know of the existance of that method.

I'll apply them on Sunday evening if nobody applied these patches
before :)

Btw, I can hear _lots_ of noise when using -S 4096, it's a bit better
when using -S 1024, and -S 512 works ok (I can hear clear sound), any
idea on anything to check ?

Also, do you think it would be possible to move the *.mcopclass and
*.mcoptype files from $kdedir/lib to another directory ? What about
$kdedir/share/arts ? (given that there's already a $kdedir/lib/Arts
directory). I don't think we should have anything else than library
files on $kdedir/lib.

Greetings,

--
Antonio Larrosa Jimenez
KDE Core developer
antonio@larrosa.org        larrosa@kde.org
http://www.arrakis.es/~rlarrosa
KDE - The development framework of the future, today.

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