Hi Stefan,
the hdparm -c1 -d1 -k1 -K1 /dev/hda did a good job with respect to the
hd-io related problems. But still the long dropouts (about 100ms to
500ms) remain. I'm not using full duplex and also tried starting
artswrapper manually which prompted the required message
>> running as realtime process now (priority 50)
Matthias
On Thu, 30 Nov 2000, Stefan Westerfeld wrote:
> 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
>
