Hi!
Here are a few things worth testing:
* does it happen with wavs, too?
* does it happen with pure synthesis, too (take artsbuilder, read the
documentation (F1)), and play a stereobeep and look if there are dropouts?
* if you can recompile it, I would be interested if the latency debugging
in IOManager finds out that there has been an exceptionally large latency.
How big is it there?
Cu... Stefan
On Fri, Dec 01, 2000 at 03:21:09PM +0100, Matthias Nagorni wrote:
> 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
> >
>
--
-* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
