Periodic sound "hiccups" for all applications
 

Hi,

I have an old NEC with a modest soundcard, and all apps with audio (Audacious, MPlayer, Flash videos, ...) suffer from periodic "hiccups".

The computer has sufficient RAM (4 GB), and I wonder what I can possibly do to solve this problem. Is there some magic kernel option I can use to solve the problem? If an eventual solution involves rebuilding the kernel, so be it.

Any suggestions?

Niki

What exactly do you mean by "hiccups"? The condition known as "clipping" could be interpreted as a hiccup sound, and I believe that occurs when the frequency range of the sound exceeds the capacity of the reproducing equipment, like your sound card.

I think the exact term is "jitter". A bit like a scratch on an old vinyl record. The sound suddenly jumps, and it's quite annoying.

It's most likely buffer under-runs caused by either the CPU or disk being busy at exactly the point in time that the buffer needs to be filled. I used to get one of these stalls when the cron.daily scripts kicked off. Problem is, it's not so easy to fix as it could be any old process that is using CPU at the wrong time . You can run your audio program with a negative nice value, but that requires root permissions to set - which is a little inconvenient. Failing that you can try and reduce the priority of background processes by using a positive nice value on them and therefore increasing the relative priority of your audio programs indirectly, but that can be a bit of a pain to setup too.

Couple of other things you might want to try.
- The CONFIG_SCHED_AUTOGROUP kernel compile-time option
- Try using the deadline I/O scheduler rather than CFQ.


Unfortunately I don't think there's a one size fits all solution, it's going to take a little trial and error.

I gave that a try, rebuilt my kernel a few times with different options as suggested and watched it chugging away drinking a few cups of coffee. To no avail.

Then I tried Audacious > Edit > Preferences and reduced the buffer from 500 to 100 ms... and the hiccup disappeared.

The other apps? Oh well, a simple rebooting seemed to solve the problem.

Slackware users are stubborn, right? :D

Nah, the problem came back. Playing flash videos for example, I get regular "jumps" in video and sound.

Now I completely forgot something very specific about my install. My /home is on the local server (HP Proliant) and mounted via NFS. I tried to move a directory containing some music to the local /tmp folder, which seems to solve the hiccup problems.

Now there's another question: how can I have seamless audio and video over NFS? It's mounted with the following options:

Jitter is something else (jitter = variance of latency). What you describe is commonly referred to as sound skipping. [NB: scheduler latency can result in sound skipping, but it's the absolute value of latency that counts, not the jitter as such]

I can only advise to run a better kernel scheduler like BFS, and if necessary to change the scheduling group of your applications (sound applications up, compiler jobs down).

For all machines i'm responsible for I roll out a kernel containing the CK patch (which includes the cpu scheduler BFS) and BFQ (a better I/O scheduler). On a work laptop laptop I dual boot win 7, and the difference is striking: on win 7 sound skips under load, whereas my patched linux kernel does not show any sound issues.

http://ck-hack.blogspot.com/

http://www.algogroup.unimore.it/peop...lo/disk_sched/

http://slackbuilds.org/result/?search=schedtool&sv=14.0

Edit: just read your last post. network latencies are a different beast altogether...

Back when reading up on for NFS (v3) tuning on a cluster setup, I looked into 5 areas that can be tweaked to improve performance:

(1) /etc/exports - using sync or async (If you want to mount with the same UID as on the host, then you have to use sync). Section 5.9
(2) Increasing the read buffer (rsize) in /etc/fstab. You have to experiment with this as the performance increase peaks at some app-dependent point. Section 5.1
(3) Using TCP instead of UDP, and, if your switch and network cards on both ends support it, using jumbo frames.
(4) Increasing the number of NFS daemons. I had to do this even for a relatively small 16 node cluster, but it probably won't help you much.
(5) Tweaking /proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max. Here are some example values from my /etc/sysctl.conf for a node with 8 GB RAM: