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

List:       kde-multimedia
Subject:    JEL - a job execution layer for aRts
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-07-18 22:48:49
[Download RAW message or body]

   Hi!

Stepping back a moment from the current PlayObject discussion (will be there
soon ;), there was one thing that is really a general in aRts currently:

We can't do ... because it takes more than ... ms. Specially in the
PlayObject discussion: we can't create a new PlayObject each time, because
it takes to long to initialize and thus causes dropouts.

But then again, if we can't create it *each time* without a dropout, we
probably can't even create it *one time* without a dropout. This is bad.

Because it means that we'll reliably have a dropout each and every time
somebody starts noatun, kaiman or whatever, when he is running low
latency. Ugly. I've throught a bit about the whole issue, and maybe found
something that might cure the problem in some cases (most?). Feedback really
highly appreciated. Probably we've got to do something here before KDE2.0.

Oh yes, if anybody has benchmarks that can exactly quantify and trace
the problem...  ;)  I'll perhaps throw some into the discussion soon, too.

But first, here is one idea how to solve this, prototype available at

   http://space.twc.de/~stefan/kde/download/jel.tar.gz

The arts-mt thingy would be another, but I think it's probably too heavy to
do for KDE2.0. Maybe KDE3.0.

Any feedback welcome. Would that allow that the mpeglib PlayObject could
always reliably initialize without dropouts?

   Cu... Stefan

JEL - an experimental job execution layer for aRts
-------------------------------------------------------------------------------

* Whats the problem?

People writing code that is supposed to run inside aRts often will need
jobs done, where they can't say exactly how long they will take. For
instance, disk access is a notoriously bad candidate. Read times or even
access times for a small file can be 10ms, maybe 20ms or 30ms, depending
on whether the file is scattered and the box is heavily loaded with other
disk I/O.

Of course, this can lead to audio dropouts (clicks) easily.

* Whats does JEL do circumvent this?

JEL offers a continously running second thread for such "dunno-how-long-
this-takes" issues. The user is supposed to make a Job derived class.
Once he creates it, somewhen the run() method of the Job derived class
will be called in the second (lowpri) thread. The Job may then perform
the task, as loading a file, calculating some complex table or something
like this.

The user of the code later can look if job->done() is true, and then
get any result data the class may have produced.

I.e.

   PrimeCalculateJob  *job = new PrimeCalculateJob(10000);

   /* later */

   if(job->done()) {
      printf("%d\n", job->primeCount());
      printf("%d\n", job->maxPrime());
   }

   /* even later */
   job->release();

The same of course works for file I/O, expensive calculations etc.

* And if there are no threads?

Then Jobs will be executed immediately as they are created. This of course
degrades realtime response on such platforms, but well, better this than
not working at all.

* Will it be in aRts/KDE 2.0?

We'll see... if it's useful? If it can solve latency problems? Maybe.


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