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

List:       kde-multimedia
Subject:    Re: mpeglib import
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2000-07-06 13:23:38
[Download RAW message or body]

> 
> 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.
>a

We should disable the yaf players if we do a KDE build.
 
> > 
> > * 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.
>

User who have droppouts during mp3 playpack will switch the player
and disable arts in less than a second.
Most likely they switch to xmms.
I can understand that we have dropouts when having a load of 2 or higher.
But when opening a window is not acceptable.

kmpg has no droppout with a load of 6 and xmms even work with a load
of 4.

Is it possible to change the buffersize withoput restarting
the whole kde/arts?
Then we can have a big buffer as default, and maybe if
a game connects we can make it less.
Can we add a "prefereedBuffersize" call when connecting to artsd?
changing it on runtime?
I think this would solve the problem.

Martin


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