Hi!
On Thu, Nov 30, 2000 at 05:01:37PM +0100, Matthias Nagorni wrote:
> There seems to be a problem with buffer underruns of artsd... I'm using
> arts as part of KDE2, Pentium III (800 Mhz), onboard sound es1371
> (Soundblaster PCI 128 compatible). I checked the problem both with OSS and
> ALSA. I generated audio streams by playing mp3's both with kaiman and with
> xmms (with aRts plugin). I used realtime priority and a chown'ed root and
> suid root artswrapper. First I tested on an almost idle system. Buffering
> problems then mainly occured on two different time scales: 1) milliseconds
> 2) seconds. 1) sounds like noise, 2) is an interrupt of the
> playback of length 500 to 2000ms. 1) only occured when setting the
> response time of the soundserver to 10 ms or standard (within KDE control
> center). The playback of kaiman seemed to be much more sensitive to
> 1) because xmms uses a 3000ms internal buffer which seems to bypass the
> problem. 1) Mainly occured when the player loaded a block of the mp3. To
> eliminate problem 1) I used the 250ms response time for further
> testing. But still 2) occured. On an idle system this buffer underrun
> occured with a frequency of sometimes only once per 15 min. somtimes more
> often. Then I performed a more heavy test: During playback I did
> cp -R /some_very_large_folder /tmp/tmp. This caused the playback to be
> heavily corrupted.
>
> Any idea what might be wrong ?
First of all, while I have really seen and heard mini-dropouts like in 1),
I can't really explain a two second dropout on an idle system. That should
not be happening. Never. Maybe it is related to you using full duplex (which
is really untested) - turn that off and retest in case you did.
You should also check that you are really using a realtime process. You
should get a message like
>> running as realtime process now (priority 50)
(either on the console when you start it manually using artswrapper, or in
.xsession-errors or something like this).
There are still several things that affect even realtime processes in
performance, some of them are
[1] out of memory situation
[2] hardware (sometimes, bad written drivers, sometimes bad hardware, which
can't be accessed in a sane way)
[3] non-latency compliant implementation of the kernel
[4] problems in the aRts implementation
There is no good general fix for [1] and [2], although for IDE in particular
(which is good at causing dropouts), I can recommend this:
hdparm -c1 -d1 -k1 -K1 /dev/hda # add other devices as needed
Against [3], there is a fix, which is called using special low latency kernels.
These are relevant when you go into low latency areas, like reliable 10ms or
20ms latency, for 250ms, a standard kernel should do.
Finally, there might always be a bug in the aRts implementation, a good place
for profiling latency related stuff is looking into the iomanager.cc code
which provides a piece of ifdefd code for latency debugging. If you find
a reproducable operation which is always or often causing a dropout, or at
least a high delay as debugged by IOManager, there might be a chance to
fix it.
Cu... Stefan
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
