[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-06 22:42:36
[Download RAW message or body]

   Hi!

On Thu, Jul 06, 2000 at 03:23:38PM +0200, Martin Vogt wrote:
> We should disable the yaf players if we do a KDE build.

Ok. Would be great if you look at this.

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

True. Is it reproducable with using realtime rights? Here a quick intro for
testing.  Suppose artsd is installed in /usr/local/kde-2.0/bin. As root, do

$ chown root / /usr /usr/local /usr/local/kde-2.0 /usr/local/kde-2.0/bin
$ chown root /usr/local/kde-2.0/bin/artsd
$ chown root /usr/local/kde-2.0/bin/artswrapper
$ chmod u+s /usr/local/kde-2.0/bin/artswrapper

As user, when starting artswrapper the next time (it accepts the same
arguments as artsd, so you can use the usual -F, -S, -n and similar args),
it should print out the success message.

$ artswrapper
>> running as realtime process now (priority 50)

Hit Ctrl+C once, then start it >/dev/null

$ artswrapper >/dev/null

It would be really interesting to see which is the minimum safe latency with
realtime rights in your configuration/stress situation.

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

It is very hard to implement, as inside artsd, there are lots of ringbuffers
which are allocated specifically adapted to the requested latency. Besides,
most of the streaming applications orient themselves on the latency, so all
apps would dynamically need to change their streaming strategy, too.

I also think it would only move the problem (not solve it), because all the
dropouts would be back once you started playing a game.

IMHO better scheduling is the way to go. The only reason while your linux
box still treats networking stuff well even if you have a load of ten is that
packets are treated when required, not using the usual timesharing. It's just
the same we need for audio stuff, and adjusting scheduling makes it possible.

   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]