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

List:       kde-multimedia
Subject:    Re: mpeglib import
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-07-05 23:12:04
[Download RAW message or body]

   Hi!

On Wed, Jul 05, 2000 at 01:16:06PM +0200, Martin Vogt wrote:
> On Wed, Jul 05, 2000 at 02:56:47AM +0200, Stefan Westerfeld wrote:
> > Other than that, mpeglib probably shouldn't install too much stuff, like
> > yaf-splay or things like that. Ideally, I think it should only install the
> > aRts plugin, nothing else. Then, people wouldn't even think of linking to
> > it directly.
> >
> If we add to the yaf-* players an artsc output then all yaf players
> become command line tools, which works with arts.
> The players should stay but maybe with an "arts" option.
> 
> To the linking problem: we should not allow that a QT/KDE GUI
> application links to mpeglib, but for the command line players
> its ok. (If mpeglib is removed, then the yaf players disappear
> as well, because they belong to mpeglib)

In the long run, I'd rather like to have one command line player only, which
deals with PlayObjects (maybe artsplay should do this?). That way, it wouldn't
only know about mpeglib based codecs, but also about others. And the user had
one unified frontend which he could use for everything installed.

Of course you could do with your kdemultimedia/mpeglib/examples like with the
sources in kdelibs/arts/examples: compile them only if make check is used, so
you can still use them for debugging.

> Can we change the "Control Center"->"Soundserver" options?
> 
> In my test even the comfortable option "250ms" is not enough.
> Every time when I open a window/close it the sound has drop
> outs.
> If you start artsd -S 8192 -F 8
> everything is fine.
> 
> The options are "misguiding".
> Many people will think, if its "fast" its "good", but what they
> want to have is a bigger buffer against droppout.
> 
> What do you think of this:
> 
> * Midi Keyboard
> * Playback
> 
> as option for artsd. Midi with the fast (10ms) and playback with
> a _big_ buffer. I think 65KB should be enough, bigger buffers
> do not work well with mpeg video. 
> And I think "playback" buffersize should be default.

I think that a soundserver only makes sense, if it

a) solves the problem that you can only use one application at once for sound
   output
b) doesn't add severe restrictions, so that you can always let it run, and
   never bother about it

Adding 400ms latency doesn't sound like a good idea to me to achieve this. Of
course I can make it an option. But it is not only unsuitable for midi and
serious audio stuff, then, it also badly breaks all games, and probably window
manager sounds, too (400ms *is* noticeable). Especially this is true as you
normally need to add another 400ms for streaming latency, if external processes
use artsd via aRts C API and similar.

So if there is the slightest chance we can avoid it, lets try to do so.

Here are a few things about latency:
- you *need* to run it as realtime process for any serious results (start
  artswrapper, not artsd, and make sure artswrapper is suid root)
- there may be bugs inside artsd and/or PlayObjects: anything that leads to
  internal processing >= 5 ms or so should be fixed
  (for instance my WavPlayObject is broken, because it loads the file at once)
- debugging printfs (especially when printed in an xterm or konsole) are often
  a problem - start artswrapper >/dev/null to see the "real" performance

Debugging a realtime process is much more tricky, because one error will
freeze your system completely (as other processes will not get CPU time).
However there probably should be a kind of watch process to avoid these
freezes.

   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]