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

List:       kde-core-devel
Subject:    Re: System Notification, knotify and Arts => unusable?
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-08-31 16:54:37
[Download RAW message or body]

   Hi!

On Thu, Aug 31, 2000 at 04:52:24PM +0200, Matthias Ettrich wrote:
> 
> Reggie and I tried the sound notifications today, on a dual P3 600 machine with
> enough memory. 
> 
> The best thing we can say is that it works, sort of. The delay between making a
> window unsticky and actually hearing a sound is something like 1.5 seconds.
> 
> This is not acceptable.
> 
> I browsed a bit in the code. There are several reasons for the slowness:
> 
> - the problem is *not* dcop that is used to communicate between kwin and
> knotify. DCOP easily makes something like 4000 sends *per* second* on a machine
> like this.
> 
> - knotify, when receiving a message, first reads in several kconfig files. That
> is completely pointless. It should store the config objects and be signalled
> any changes from the control center module to call "repareConfiguration."
> Charles and Stefan, you both are listed as authors, can you please fix that?
> 
> - arts, when playing a sound file, doesn't seem to do any caching whatsoever
> but prints out lots of debug output instead.
> 
> Still the debug output and the missing caching cannot be it. It's actually
> faster to launch a console application to play that sound (like 'cat'). 
> 
> Do we have minor optimization issues here or a conceptual problem? Until
> somebody conviences me otherwise, I assume a conceptual problem. Arts
> apparently isn't suited for playing sounds. Wasn't that what the KDE sound
> server was about?

The first two reasons you mentioned can be measured, and for my system it is
something like 30 ms (which is the path from kwin to dcopserver to knotify
to artsd, until artsd has initialized an object playing the sample). I did
acquire this by inserting two gettimeofday printfs, one into kwin and one
in artsd after loading and starting the wave file.

Arts does caching (so it only loads the sample the first time), and the
debugging output shouldn't be that bad, especially if you don't show it on
the X screen (but maybe in .xsession-errors).

I think by far the largest portion of latency is the amount of buffering
aRts uses for the soundcard output. It works like a pipe, where aRts stuffs
new data in at the end, and the speakers play the data at the other end, like

  aRts -> [    soundcard buffer    ] -> speakers

This one is configurable and adds a latency of 10 ms .. 250 ms, depending on
what you choose in kcontrol. It seems that for dropout free audio output, a
250 ms buffer is just about good enough, when not using realtime rights. So
this is the current default for KDE2.0.

Whether or not it is a conceptual problem that aRts does refill the buffer
even if you don't play samples is debatable, but it is the reason why a
system("play foo.wav"); feels faster than an system("artsplay foo.wav");,
as the first doesn't start with an already zero-sample-filled buffer.

Tuning both to the same speed might be possible with a band-aid-patch,
it could however not provide a general solution, because *if* you are
playing an mp3 with kaiman in the background, you *do need buffering*, and
thus you won't get around having the additional latency, then. Use xmms
and turn the parametric eq on and off and watch the delay between pressing
the button and hearing the result to see what I mean.

Anyway, anything like 1.5 sec shouldn't happen with knotify/artsd, except
if you use a sample which starts with 1.2 seconds of silence ;-)

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

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