patch-2.1.128 linux/drivers/sound/Readme.modules

Next file: linux/drivers/sound/ad1848.c
Previous file: linux/drivers/scsi/scsicam.c
Back to the patch index
Back to the overall index

diff -u --recursive --new-file v2.1.127/linux/drivers/sound/Readme.modules linux/drivers/sound/Readme.modules
@@ -66,6 +66,34 @@
 
  recommend using /etc/modules.conf.
 
+Persistent DMA Buffers:
+
+The sound modules normally allocate DMA buffers during open() and
+deallocate them during close(). Linux can often have problems allocating
+DMA buffers for ISA cards on machines with more than 16MB RAM. This is
+because ISA DMA buffers must exist below the 16MB boundry and it is quite
+possible that we can't find a large enough free block in this region after
+the machine has been running for any amount of time. The way to avoid this
+problem is to allocate the DMA buffers during module load and deallocate
+them when the module is unloaded. For this to be effective we need to load
+the sound modules right after the kernel boots, either manually or by an
+init script, and keep them around until we shut down. This is a little
+wasteful of RAM, but it guarantees that sound always works.
+
+To make the sound driver use persistent DMA buffers we need to pass the
+sound.o module a "dmabuf=1" command-line argument. This is normally done
+in /etc/conf.modules (or the more proper /etc/modules.conf) like so:
+
+options sound		dmabuf=1
+
+If you have 16MB or less RAM or a PCI sound card, this is wasteful and
+unnecessary. It is possible that machine with 16MB or less RAM will find
+this option useful, but if your machine is so memory-starved that it
+cannot find a 64K block free, you will be wasting even more RAM by keeping
+the sound modules loaded and the DMA buffers allocated when they are not
+needed. The proper solution is to upgrade your RAM. But you do also have
+this improper solution as well. Use it wisely.
+
   I'm afraid I know nothing about anything but my setup, being more of a
 text-mode guy anyway. If you have options for other cards or other helpful
 hints, send them to me, Jim Bray, jb@as220.org, http://as220.org/jb.

FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen, slshen@lbl.gov