These are **old** tips on how to deal with audio dropouts
on a non-LowLatency kernel. It is not recommended that you follow these tips, unless you really have to. The LowLatency
solution is better.

The general strategy was:

Reduce System Activity.

Here are some specific tips on how to do that. These were originally contributed by Ralf Schlatterbeck, Michael Stutz, Michael Brown, and Jim Jackson.

The driver you're using may have some options that could help. For instance, the OSS-Free kernel driver has a dma buffersize
    compile-time option. This should be set as high as it can go. If you're still having problems, it's time to look at what else is running
    on your system. You may be able to trim a lot of fat.

*    Close unused xterms and other applications.

*    Don't run X if you can avoid it.

*    Try using a command-line recorder like ecasound or ALSA's arecord or the Sox rec script, to avoid the overhead of
    running a graphical sound editor.

*    Improve the scheduling priority for the command you're running by using nice as root. Set a low, possibly negative, number.

*    Try (as root) killing unneeded getty's.

*    Kill off syslogd. Whenever it logs a message it syncs the disks. This "...can be a real pig on a low end machine." Or edit the
    syslog.conf to omit synchronizing by prefixing the filename(s) with a '-'.

*    Kill sendmail.

*    Kill crond.

*    You could even go so far as to reboot in single-user mode. Yikes.

*    You probably should **not** bother with RTLinux (at http://luz.cs.nmt.edu/~rtlinux ). RTLinux can theoretically provide extremely reliable performance at *extremely* low latencies, like well under one millisecond. But to get this, you have to do a LOT of work: apparently you need special RTLinux-compatible device drivers, which probably don't
    exist for your soundcard, and there are rigorous restrictions on how the applications can be coded, so this is really only a
    theoretical solution. But if you're a real wizard and your really need the absolute best possible realtime performance, it might be
    worth spending some months (years?) of your life going in this direction.

*  Try the "scheduler bigpatch" by Rik Reil at http://humbolt.geo.uu.nl/~riel/patches/. This is now rather old and I don't know
    anything about it; I think it may be unnecessary with later 2.2 kernels?

*    Alex Dolski solved his Vibra 16's dropout problems by reading the...

"readme file called 'VIBRA16' in Documentation/sound of the Linux kernel sources ... which seemed to explain the
       problem I was having. It says that the card (or the driver for the card) for some reason supports two 8-bit DMAs but no
       16-bit DMA, but the second 8-bit DMA must be passed as a 16-bit DMA to make the sb.o module happy. However, I
       find that with no 16-bit DMA channel, sound becomes very distorted during periods of hard disk activity...." 
       "The solution I found was to issue the command hdparm -d 0 /dev/hda to turn that hard disk DMA off. Once
       I did this, everything sounded fine, but there was a definite reduced CPU efficiency of disk transfers." 
       "I probably wouldn't have brought this up if the VIBRA16 readme didn't say that this problem is experienced by 'almost
       all soundcards.'"

*    If you get dropouts while recording on a system with an older CPU (like, say, a 486), Ralf Schlatterbeck suggests that

"...Your recording program does not consume data with the rate it is procuced by the sound card. This results in audible
       clicks and you will see the following entries in syslog: 
       Apr 26 14:46:17 cat kernel: Sound: Recording overrun 
       You can solve these problems (assuming your hardware is capable of a sustained data rate you need) by using
       software that has a low overhead when recording. I have very good results with gramofile cardit.et.tudelft.nl/~card06/
       and bplay (available from sunsite, also included in the debian distribution). The bplay program has the additional
       advantage that you can set up recording using 'at' or 'cron' to record from radio..."

*    Another possible problem suggested by Ralf Schlatterbeck:

"You are using several DMA devices (one of them being the soundcard). You will NOT see the overrun message
       above, but the effect is very similar. I got several very audible clicks every 5 seconds or so.... The clicks turned out to
       be correlated with the "sync" when Linux writes out the accumulated sound data to disk. Note that due to buffering you
       might not see this effect until after a minute or so. I solved the problem by experimenting with Linux' buffer settings in
       /proc/sys/vm/bdflush This is a special file that controls when and how Linux writes accumulated data to disk. The file is
       writeable by root and you can simply echo the new parameters to this file. The original settings that caused the
       problems were 60 500 64 256 15 3000 500 1884 2 and the parameters that solve the problems
       above (for me) are 0 50 40 256 15 3000 500 1884 2 
       This effectively tells Linux to try to keep the buffered data to zero, but not to write too much data in one blow. So the
       two DMAs (of disk and audio card) do no harm to each other. Note that this setting tunes Linux just for audio recording
       and the system will not behave very well when confronted with other tasks!"

*    Ralf Schlatterbeck writes,

"The sound driver is using dynamically allocated kernel memory and you don't get enough buffer space for the DMA
       buffers. This problem may result in clicks and other strange sound-effects.... 
       "Typically the sound driver coming with the linux kernel ... has a setting how much buffer space it should allocate. The
       space, however, is dynamically allocated when opening the sound device. 
       On a long running system, the kernel tends to allocate all the free memory to buffer space (used for disk I/O buffers),
       and the in-kernel memory allocation the sound driver uses does not seem to allocate this space. 
       If no space could be allocated you will get a message from the kernel and the recording program will get an error. If,
       however, some space could be allocated, but not the full buffer space that was compiled into the driver, most recording
       program will silently use the low memory for the DMA buffer. Since most sound recording programs do not check how
       much memory was actually allocated, results of recordings may not be what you expect and the results are often
       non-reproduceable. 
       A sound-recording program should have an option to display the amount of memory allocated for DMA buffers, the
       code is something like:

<pre>

struct audio_buf_info info;
                     if (ioctl(audio, getspace, &info) < 0)
                     { 
                          /* error message and/or exit */ 
                     }
               -- pr fprintf ( stderr 
                             , "Allocated %d fragments of size %d\n" 
                             , info.fragstotal 
                             , info.fragsize 
                             );

</pre>

A work-around for this bug (probably already fixed in later kernels ?) is to explicitly free the buffer space by allocating a
       large amount of user-memory, I call the following code before recording audio to reset the buffer cache (This is for my
       32MB 486, you may or may not want to increase the amount of allocated memory on a larger machine -- try it out):

<pre>

#include <stdlib.h>
             main()
                  {
                      char *p = malloc(1024 * 1024 * 32);
                      int i;
                      for (i=0; i<1024 * 32; i++)
                      {
                          p[i*1024] = 0;
                      }
                  }

</pre>

* Jim Jackson suggests, "Don't run top or similar, which make extensive use of the /proc file system." This can cause dropouts.

* Jim Jackson writes: "With IDE disks, make sure you use the hdparm utility to set -u1 which runs the bottom half IDE processing with  other interrupts enabled. This processing can be time consuming. ... The manual hands out dire warnings about use of some  parameters, but AFAIK the only potential problems are with some very old IDE controllers/chipsets. Alan Cox claims to actually    know of a problem (corruption) being caused by the use of hdparm -u1 but this was several years ago and was old hardware   then."