The K Desktop Environment

13.3. Latency

13.3.1. I sometimes hear short pauses when listening to music, is this a bug?
13.3.2. What's the effect of the response time setting?
13.3.3. Is there anything else I can do to prevent pauses?
13.3.4. Why is artsd taking so much CPU time?

13.3.1. I sometimes hear short pauses when listening to music, is this a bug?

This is most likely not a bug, but caused by the fact that the Linux® kernel is not very good at real-time scheduling. There are situations where aRts will not be able to keep up with playback. You can, however, enable real-time rights (via KDE Control Center:), and use a large latency setting (like 250ms or don't care), which should improve the situation.

13.3.2. What's the effect of the response time setting?

The help text for this setting in the KDE Control Center can be misleading. A lower value means that aRts will take less time to respond to external events (i.e.. the time that it takes between closing a window and hearing a sound played by artsd). It will also use more CPU resources, and be more likely to cause dropouts.

13.3.3. Is there anything else I can do to prevent pauses?

For users of IDE drives, you can use the hdparm command to put your IDE drive in DMA mode. A word of warning: this does not work on all hardware, and can result in having to do a hard reset or in rare cases, data loss. Read the documentation for the hdparm command for more details. I have successfully used the following command:

 % hdparm -c1 -d1 -k1 -K1 /dev/hda

You need to run this after every boot, so you might want to place it in a system startup script (how to do this distribution specific, on Debian Linux® it is usually put in /etc/rc.boot).

13.3.4. Why is artsd taking so much CPU time?

Check your response time settings. However, the current version is not yet really optimized. This will improve, and until then no real prediction can be made how fast artsd can or can't be.