Skip to contentSkip to conversation

Updates to Maestro{1,2,2E} driver -- multiple open of dsp, persistent buffers.

PATCH In review Daniel Pittman 2 participants 2 messages Jul 6, 2001

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Updates to Maestro{1,2,2E} driver -- multiple open of dsp, persistent buffers.

The attached patch modifies the kernel Maestro sound driver to add a couple of features:

* open /dev/dsp many times, not /dev/dsp[0-3]
* persistent DMA buffers

This code has been well tested and has run for quite a long time with stability and success on a number of Maestro-using computers.

The patch has the blessing of Zach Brown, the current maintainer, as far as that goes -- but it's my own work. :)

It would be good if people could test this and let me know if they encounter any problems. If not, I will submit it for inclusion in the kernel proper soon.

The patch is against 2.4.7-pre3 but should apply successfully to version 2.4.6 or later.

Daniel

Documentation/Configure.help +16 -0
diff -ru linux/Documentation/Configure.help linux.maestro/Documentation/Configure.help
@@ -15607,6 +15607,22 @@
   of PCI sound chips.  These include the Maestro 1, Maestro 2, and
   Maestro 2E.  See Documentation/sound/Maestro for more details.
 
+The number of DSP device to create.
+CONFIG_MAESTRO_CHANNELS
+  The number of DSP devices to allocate. Each device functions as
+  a fully independent sound system. The more devices allocated,
+  however, the larger the memory requirement for the driver.
+  You can allocate up to four DSP devices, but only in multiples
+  of two. This allows one, two or four devices.
+
+Allocate memory for DSP devices persistently
+CONFIG_MAESTRO_PERSIST
+  If you say Y to this, the memory for the DSP devices provided
+  by the Maestro device will be retained even when the sound
+  system is not in use.
+  This is beneficial if you find that sound cannot be used after
+  doing other things on the machine for a while.
+
 Are you using a crosscompiler
 CONFIG_CROSSCOMPILE
   Say Y here if you are compiling the kernel on a different
Documentation/sound/Maestro +26 -10
diff -ru linux/Documentation/sound/Maestro linux.maestro/Documentation/sound/Maestro
@@ -80,16 +80,32 @@
 an IRQ.  This operation is incredibly system specific, so you're on your
 own.  Sometimes the magic lies in 'PNP Capable Operating System' settings.
 
-There are very few options to the driver.  One is 'debug' which will 
-tell the driver to print minimal debugging information as it runs.  This
-can be collected with 'dmesg' or through the klogd daemon.
-
-The other, more interesting option, is 'dsps_order'.  Typically at
-install time the driver will only register one available /dev/dsp device
-for its use.  The 'dsps_order' module parameter allows for more devices
-to be allocated, as a power of two.  Up to 4 devices can be registered
-( dsps_order=2 ).  These devices act as fully distinct units and use
-separate channels in the maestro.
+There are very few options to the driver. Options can be specified as either
+module options or on the kernel command line. Command line arguments are in
+the form 'maestro=<option>:<value>,<option>:<value>'.
+
+One is 'debug' which will tell the driver to print minimal debugging
+information as it runs. This can be collected with 'dmesg' or through the
+klogd daemon. Setting this to one will cause debug information to be dumped.
+
+The other, more interesting option, is 'channels'. At install time the driver
+will register /dev/dsp and makes a number of channels available through this
+device. Multiple programs can open /dev/dsp, until all channels are used.
+
+The 'channels' parameter specifies the number of channels to be specified. Up
+to 4 channels can be allocated, but only in powers of two. Thus, you can have
+one, two or four devices. The default value is to allocate one channel.
+
+When multiple channels are open, they act as distinct sound devices. This
+allows multiple applications to generate sound simultaneously without blocking
+each other.
+
+At compile time you may also select to use persistent dsp buffers. Because of
+some oddities of the hardware, a large number of channels requires a large
+slab of contiguous memory. The persistent buffers option allocates this memory
+when the cards are detected and holds it all the time, preventing memory
+fragmentation from preventing the sound device from working.
+
 
 Power Management
 ----------------
drivers/sound/Config.in +4 -0
diff -ru linux/drivers/sound/Config.in linux.maestro/drivers/sound/Config.in
@@ -36,6 +36,10 @@
 dep_tristate '  Creative Ensoniq AudioPCI 97 (ES1371)' CONFIG_SOUND_ES1371 $CONFIG_SOUND $CONFIG_PCI
 dep_tristate '  ESS Technology Solo1' CONFIG_SOUND_ESSSOLO1 $CONFIG_SOUND
 dep_tristate '  ESS Maestro, Maestro2, Maestro2E driver' CONFIG_SOUND_MAESTRO $CONFIG_SOUND
+if [ "$CONFIG_SOUND_MAESTRO" = "y" -o "$CONFIG_SOUND_MAESTRO" = "m" ]; then
+   int  '    Number of channels (1,2,4)' CONFIG_MAESTRO_CHANNELS 1
+   bool '    Persistent Maestro dsp buffers' CONFIG_MAESTRO_PERSIST
+fi
 dep_tristate '  ESS Maestro3/Allegro driver (EXPERIMENTAL)' CONFIG_SOUND_MAESTRO3 $CONFIG_SOUND $CONFIG_PCI $CONFIG_EXPERIMENTAL
 dep_tristate '  Intel ICH (i8xx) audio support' CONFIG_SOUND_ICH $CONFIG_PCI
 dep_tristate '  S3 SonicVibes' CONFIG_SOUND_SONICVIBES $CONFIG_SOUND
drivers/sound/maestro.c +306 -218

878 lines not on this page · raw message

Signature · 3 lines
-- 
Sweet is pleasure after pain.
        -- John Dryden,  _Alexander's Feast_, 1697
#1 lore raw
Quoted 2 lines

The patch has the blessing of Zach Brown, the current maintainer, as far as that goes -- but it's my own work. :)

You need to keep the dsp_order option as people have stuff relying on it (at least for 2.4). It doesnt need to be documented or the recommended way (and I agree its a bit strange) but it needs to work