Difference between revisions of "Tips And Tricks"

From Open Sound System
Jump to: navigation, search
(Added multimedia key idea from Archlinux wiki page for OSS)
(ALSA Emulation)
 
(112 intermediate revisions by 29 users not shown)
Line 1: Line 1:
== Tips ==
+
=== Changing the default sound output ===
=== Starting ossxmix minimized to tray on desktop startup ===
+
<span id="Changing the default sound output used for /dev/dsp"></span>
The '-b' option starts ossxmix in the background - minimized to tray if tray support is compiled in, iconfied window if not.
+
#* The typical method is to relink /dev/dsp to the desired /dev/oss/.../ device. e.g.
The '-S' option prevents ossxmix from trying to use a system tray. ossxmix -Sb' will always start an iconified window.
+
#::  sudo ln -sf /dev/oss/oss_sbxfi0/pcm0 /dev/dsp
#KDE: create a desktop shortcut in ~/.kde/Autostart with the command 'ossxmix -b'.
+
#:The device node matching the desired sound output can be discovered by running 'osstest' (and seeing which node produces the desired output) or by examining 'ossinfo -a' (displays list of nodes).
#:Alternative: create a desktop shortcut in the same place, with the command "ossxmix -Sb'. Go to Applications->"Advance options" and select "Place in system tray".
+
#* It's highly recommended to make vmix attach to the newly default device. vmix is OSSv4's software mixer and multiple programs will usually not be able to use the output at the same time if it's not attached. Since the default output was changed, vmix will have to be set to attach to the new output.
#Gnome: go to Control center->Session->"Startup Programs" and add "ossxmix -b".
+
#*: In OSS 4.1 and above, add a "vmixctl attach" to be run after OSS is loaded. This can be done by [[Tips And Tricks#Running a command immediately after OSS is loaded|editing the soundon.user file]]. It is also recommended to also add "vmix_no_autoattach=1" line to the [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/conf/osscore.conf file (so vmix won't use the old default too). "vmixctl attach" syntax looks like this:
#X11 in general: edit the Xsession file. Make sure the tray program runs before ossxmix, or use the '-S' switch as well.
+
#*: vmixctl attach /dev/oss/oss_sbxfi0/pcm0 /dev/oss/oss_sbxfi0/pcmin0
#See [http://gentoo-wiki.com/HOWTO_Autostart_Programs] for info on other environments.
+
#*::The second and third argument represent output and input nodes for vmix to attach to, allowing full duplex when /dev/dsp is used. However, the third argument can be omitted in some cases. See "vmixctl" manpage for explanation.
 +
#*: In OSS 4.0 you'll need to set vmix_masterdev in [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/conf/vmix.conf file.
 +
#* Modern OSs put /dev on a ramdisk (i.e. it gets erased in boot), so we need to make sure the new correct setting remains. OSSv4.2 and above stores /dev/dsp setting in [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/etc/legacy_devices, so these should be saved automatically as long as OSS is shut down properly (You can run "sudo ossdevlinks" to save this manually).
 +
#:: OSSv4 before version 4.2 requires editing the [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/soundon.user file again and placing the relinking command there. This would also work with newer OSSv4 versions.
 +
# Alternative: If the default output is set to an onboard soundcard and you're using another card, you can just disable onboard audio in the BIOS, and it won't be seen by OSS.
 +
# Alternative: $OSSLIBDIR/etc/installed_drivers influences the order of sound cards set by ossdetect. By removing other devices or moving the desired sound card to the first place, the default device can be modified. After the change, restart OSS and run "sudo ossdevlinks -v -r" and it will relink /dev/dsp for you.
  
=== Changing the default sound output used for /dev/dsp ===
+
==== OSSLIBDIR location ====
# Relink /dev/dsp to the desired /dev/oss/.../ device. The device node matching the desired sound output can be discovered by running 'ossinfo -a'. If OSS insists on recreating /dev/dsp, simply add the appropriate linking command (typically ln -sf /dev/oss/.../ /dev/dsp) to $OSSLIBDIR/soundon.user.
+
<span id="OSSLIBDIR"></span>
# Alternative: $OSSLIBDIR/etc/installed_drivers influences the order of sound cards set by ossdetect. By removing other devices or moving the desired sound card to the first place, followed by running 'ossdetect -v', the default device can be modified.
+
* The OSSv4 root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is almost always /usr/lib/oss/.
#: The root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is typically /usr/lib/oss/.
+
  
 
=== Recording sound output of a program ===
 
=== Recording sound output of a program ===
There are several methods to achieve this:
+
There are two main scenarios here:
# Many drivers offer a 'vol' mixer control. If this is used as a recording source, than the current sound output will be recorded. Note that this is the mixed total of all sound played, not of a single program.
+
# Trying to record the entire desktop. Since more than one app may be playing, we want the total mixed output.
#: ossrecord -ivol blah.wav
+
# Trying to record one specific app. This can be accomplished using solutions for the above (if nothing else is playing), but there are some more options here.
# OSS wrappers can be used to record the output of a program. vsound is one such wrapper. (vsound doesn't handle output to /dev/oss/* device nodes, but all OSS-supporting programs are/can be easily made to output to /dev/dsp).
+
 
 +
===== Recording total mixed output =====
 +
# vmix loopback driver can record the mixed output of sound played. Set vmix_loopdevs to 1 (or 2) in [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/conf/osscore.conf, and restart OSS. Then record from the newly created loopback device ("ossinfo" command will display the device list, including the new device). Note that this is the mixed total of all sound played via vmix, not of a single program.
 +
#: ossrecord -s48000 -b16 -c2 -d/dev/oss/oss_hdaudio0/loop0 test.wav
 +
#* Note that if vmixctl is used to (re)attach vmix, than 'ossdetect -d' is needed to be used after vmixctl to create the loop device.
 +
#* Old OSSv4 versions (v4.0 before build 1016), used vmix.conf and not osscore.conf for this purpose, using the line "vmix1_numloops=1". Recording from vmix loopback didn't work in OSSv4.0 build 1016.
 +
#* The recording program should expect the format, number of channels and sample rate to be the same as the ones used by vmix to "talk" to the device. The rate can be seen in the mixer (via ossxmix or ossmix) and set via the "sudo vmixctl rate" command. The number of channels is set via vmix0-channels control in the mixer (this is typically set to "Stereo"). The format is typically signed 16 bit. For example, if the above ossrecord line gives an error like: ''/dev/oss/oss_hdaudio0/loop0 doesn't support 2 channels (8)'', then vmix0-channels should be set to stereo.
 +
# Alternative: Many drivers offer support for loopback recording via the hardware. This is typically done with the 'vol' mixer control. If this can be used as a recording source, than the current sound output will be recorded. Note that this is the mixed total of all sound played, not of a single program.
 +
#: ossmix vol.rec ON #sets 'vol' as default target, so any recording program uses it by default
 +
#: ossrecord blah.wav
 +
#* Some drivers have a 'loopback' mixer control (instead of 'vol'), which offers similar functionality. This can be set by ossmix or ossxmix mixer control programs.
 +
 
 +
===== Recording output of a single program =====
 +
# oss_userdev or oss_audioloop can also be used to record the output of a single program. Both the recorder and player will need to use the new node created by these drivers, and the recorder has to explicitly set up the appropriate format. oss_userdev can be used to serve multiple clients. See "oss_audioloop" and "oss_userdev" manpages for more information.
 +
#* After manual loading of oss_userdev, a new mixer device is created. You'll have to run "sudo ossdetect -d" in order to be able to use it.
 +
# Alternative: OSS wrappers can be used to record the output of a program. [http://www.vsound.org/ vsound] is one such wrapper. (vsound doesn't handle output to /dev/oss/* device nodes, but all OSS-supporting programs are/can be easily made to output to /dev/dsp).
 
#: vsound ossplay test.wav
 
#: vsound ossplay test.wav
# (This method doesn't work in build 1016) vmix loopback driver can record the output of a program. Set vmix_numloops to 1 (or more) in vmix.conf, and make the program output to the newly created /dev/oss/vmix0/loop0 device. Then record from that device. e.g.
 
#: ossplay test.wav -d/dev/oss/vmix0/loop0 &
 
#: ossrecord test2.wav -d/dev/oss/vmix0/loop0
 
  
=== Using your multimedia keys with OSS ===
+
=== Running a command immediately after OSS is loaded ===
# First, we should make the keys be able to start external scripts. This is outside the scope of this wiki, but is documented at [http://gentoo-wiki.com/HOWTO_Use_Multimedia_Keys] and at [http://wiki.archlinux.org/index.php/Extra_Keyboard_Keys].
+
The OSS startup script runs the file [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/soundon.user after OSS has loaded if the file has executable permissions. So the procedure is obvious:
# Then, we can use scripts like the examples below:
+
#Edit the [[Tips And Tricks#OSSLIBDIR|$OSSLIBDIR]]/soundon.user file and add that command before the "exit 0" line. If the file doesn't exist, you may create it as a shell script.
lowervolume.sh:
+
#Make sure that soundon.user has the executable bit set (it is not set by default).
 +
One possible use of this is to have some volume controls set to a fixed level after OSS is started, regardless of their previous level last time OSS was run (by default, OSS restores the previous volume for all controls).
 +
 
 +
=== Swapping channels system-wide ===
 +
*In OSSv4.2 build2004 and above, this can be done using the 'vmixctl remap' command. e.g.:
 +
::sudo vmixctl remap /dev/dsp 2 1 #Swaps left and right
 +
:*This requires vmix to be attached to the output used.
 +
:*If you wish to do this every startup, see [[Tips And Tricks#Running a command immediately after OSS is loaded|running a command after OSS is loaded]].
 +
:*The swap won't affect 'osstest' as it uses an uncommon interface by default, but just about every other program using the output will be affected. 'osstest -V' would also be affected by the remapping, and can be used for testing.
 +
:*See 'vmixctl' manpage for more details.
 +
 
 +
=== Using multimedia keys with OSS ===
 +
# First, we should check if the keys are recongnized by X11 or some other program. Run xev, and see if pressing the keys elicits a response.
 +
#* If it does not, than we must make the keys be recognized by X11/WM/etc., before they can be used for anything. This is outside the scope of this wiki, but is documented at [http://en.gentoo-wiki.com/wiki/Multimedia_Keys] and at [http://wiki.archlinux.org/index.php/Extra_Keyboard_Keys]. Some WMs, once set up, will automatically connect the multimedia keys to appropriate functions.
 +
# If/once the keys are recognized, does it work out of the box?
 +
#* If not, it may be a function of old gstreamer version. Gnome uses gstremaer for this, but older gstreamer didn't support OSSv4. See [[Configuring_Applications_for_OSSv4#Gnome_Volume_Applet]] for a possible solution.
 +
#* If the above does not work or is not applicable, we can connect the keys to external scripts which will perform the appropriate function (See examples below). The method to connect external scripts to keys is better described at [http://en.gentoo-wiki.com/wiki/Multimedia_Keys] and at [http://wiki.archlinux.org/index.php/Extra_Keyboard_Keys] again.
 +
#** For example in KDE, you can start the "Control Center", enter "Regional & Accessibility" -> "Input Actions", click on "New Action" and make its type "Keyboard Shortcut -> Command/URL", and then set the multimedia key to launch the script. (Names can be different due to localizations).
 +
 
 +
===== External scripts which can control volume =====
 +
====== mute.sh ======
 +
#!/bin/sh
 +
CTRL=vmix0-outvol
 +
touch $HOME/.volume
 +
VOLUME=$(cat $HOME/.volume)
 +
CURRENT=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 +
if [ $CURRENT = "0.0" ]; then
 +
      ossmix $CTRL $VOLUME
 +
      > $HOME/.volume
 +
else
 +
      VOLUME=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 +
      ossmix $CTRL 0
 +
      echo $VOLUME > $HOME/.volume
 +
fi
 +
 
 +
====== ossvol ======
 +
If you want the ability to mute and then unmute/increase volume at the same time the following script is one option. (This script relies on OSSv4.1 functionality - see note on ossmix below).
 +
 
 +
[http://ossvol.sourceforge.net ossvol]:
 +
 
 +
#!/bin/bash
 +
#
 +
# ossvol is a simple script to manage oss volume levels and muting.
 +
#
 +
# Script by: Daniel J Griffiths <ghost1227@archlinux.us>
 +
# Configure stuff
 +
VOLSTORE=~/.volume
 +
CHANNEL="vmix0-outvol"
 +
ARGUMENT=$2
 +
# You shouldn't have to edit below here.
 +
err() {
 +
    echo "$1"
 +
    exit 1
 +
}
 +
usage() {
 +
    echo "usage: ossvol [option] [argument]"
 +
    echo
 +
    echo "Options:"
 +
    echo "    -i, --increase - increase volume by [argument]"
 +
    echo "    -d, --decrease - decrease volume by [argument]"
 +
    echo "    -t, --toggle  - toggle mute on and off"
 +
    echo "    -h, --help    - display this"
 +
    exit
 +
}
 +
toggle() {
 +
    if [ -f $VOLSTORE ]; then
 +
        ossmix $CHANNEL `cat $VOLSTORE`
 +
        rm $VOLSTORE
 +
    else
 +
        VOLUME=$(ossmix $CHANNEL | awk '{print $10}' | awk -F : '{print $1}')
 +
        ossmix $CHANNEL 0
 +
        echo $VOLUME > $VOLSTORE
 +
    fi
 +
}
 +
increase() {
 +
    if [ -f $VOLSTORE ]; then
 +
        TMPVOL=`cat $VOLSTORE`
 +
        NEWVOL=`expr $TMPVOL + $ARGUMENT`
 +
        ossmix $CHANNEL +$NEWVOL
 +
        rm $VOLSTORE
 +
    else
 +
        ossmix $CHANNEL +$ARGUMENT
 +
    fi
 +
}
 +
decrease() {
 +
    if [ -f $VOLSTORE ]; then
 +
        TMPVOL=`cat $VOLSTORE`
 +
        NEWVOL=`expr $TMPVOL - $ARGUMENT`
 +
        ossmix $CHANNEL -- -$NEWVOL
 +
        rm $VOLSTORE
 +
    else
 +
        ossmix $CHANNEL -- -$ARGUMENT
 +
    fi
 +
}
 +
case "$1" in
 +
    '-i'|'--increase')
 +
    increase
 +
    ;;
 +
    '-d'|'--decrease')
 +
    decrease
 +
    ;;
 +
    '-t'|'--toggle')
 +
    toggle
 +
    ;;
 +
    ''|'-h'|'--help')
 +
    usage
 +
    ;;
 +
    *)
 +
    err "Unrecognized option \`$1', see ossvol --help"
 +
    ;;
 +
esac
 +
 
 +
OSSv4.1 includes an ossmix which allows you to change volume in a relative fashion: 'ossmix vmix0-vol -- -2' and 'ossmix vmix-vol +2'. The two scripts below can be used to have this functionality in OSSv4.0:
 +
 
 +
====== lowervolume.sh ======
 +
  #!/bin/sh
 
   CTRL=vmix0-vol
 
   CTRL=vmix0-vol
 
   VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 
   VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
   VOL=$(echo $VOL-2 | bc)
+
   VOL=$(echo $VOL | awk '{print $1-2}')
   ossmix $CTRL $VOL
+
   ossmix -- $CTRL $VOL
  
raisevolume.sh:
+
====== raisevolume.sh ======
 +
  #!/bin/sh
 
   CTRL=vmix0-vol
 
   CTRL=vmix0-vol
 
   VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 
   VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
   VOL=$(echo $VOL+2 | bc)
+
   VOL=$(echo $VOL | awk '{print $1+2}')
 
   ossmix $CTRL $VOL
 
   ossmix $CTRL $VOL
 
mute.sh:
 
  #!/bin/bash
 
  CTRL=vmix0-vol
 
  VOLUME=$(cat $HOME/.volume)
 
  if [ -z "$VOLUME" ]; then
 
        VOLUME=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 
        ossmix $CTRL 0
 
        echo $VOLUME > $HOME/.volume
 
  else
 
        ossmix $CTRL $VOLUME
 
        > $HOME/.volume
 
  fi
 
This will restore the previous volume levels when unmuting. Issue a:
 
  touch $HOME/.volume
 
before using the first time.
 
  
 
You may wish to modify a different mixer control than vmix0-vol. In that case, you will need to change the value of CTRL above.
 
You may wish to modify a different mixer control than vmix0-vol. In that case, you will need to change the value of CTRL above.
 +
 +
=== ALSA Emulation ===
 +
*There are two main methods to achieve this:
 +
<ol>
 +
<li>libasound2's pcm-oss plugin:
 +
* Easiest method, but will not work with all programs. It works by making libasound use OSS via the pcm-oss plugin.
 +
* First, install the pcm-oss plugin. It is included in the alsa-plugins distribution.
 +
** Debian: install libasound2-plugins package.
 +
* Make sure an ~/.asoundrc file exists. It should contain the lines below:
 +
<pre>
 +
  pcm.!default
 +
  {
 +
    type oss
 +
    device /dev/dsp
 +
  }
 +
  mixer.!default
 +
  {
 +
    type oss
 +
    device /dev/dsp
 +
  }
 +
</pre></li>
 +
<li>
 +
libasound2's pulseaudio plugin:
 +
* Another easy method. Again, libasound must be set up to use Pulseaudio (which is done by default with many distros). Then Pulseaudio must be [[Configuring_Applications_for_OSSv4#Pulseaudio|set up to use OSS]].
 +
</li>
 +
<li>
 +
OSSv4 cuckoo module:
 +
* Harder, and will fail on most systems. It works by representing OSSv4 drivers as a soundcard to the ALSA modules, and supplying a "driver" for them.
 +
* Note that using pcm-oss conflicts with cuckoo - libasound needs to output to ALSA's device files, so rename ~/.asoundrc if you were using pcm-oss before doing this.
 +
*: Also, nearly all the commands below require root permissions.
 +
** First, we need to get the ALSA modules back:
 +
*** Goto /lib/modules/$(uname -r)/, and extract the sound-preoss.tar.bz2 file.
 +
*** We need to prune out the OSS emulation modules, since these might conflict with actual OSS, so run "rm -rf kernel/sound/core/oss".
 +
** Second, goto /usr/lib/oss/cuckoo, and run "make install".
 +
** You can now run "modprobe cuckoo", and test with "speaker-test" etc. whether this works.
 +
** To make this stick, we need to edit the startup script, so that it loads cuckoo after loading OSS. Edit $OSSLIBDIR/soundon.user, and add "modprobe cukoo" before "exit 0" line.
 +
</li>
 +
*A general problem with ALSA emulation is that some programs probe for driver support in the order "ALSA, OSS". So programs that were using OSS by default may now try to use the emulation with possibly inferior results. So if there are problems after installation, make sure the program uses the OSS support if available rather than the emulation.

Latest revision as of 09:05, 7 July 2012

Changing the default sound output

    • The typical method is to relink /dev/dsp to the desired /dev/oss/.../ device. e.g.
    sudo ln -sf /dev/oss/oss_sbxfi0/pcm0 /dev/dsp
    The device node matching the desired sound output can be discovered by running 'osstest' (and seeing which node produces the desired output) or by examining 'ossinfo -a' (displays list of nodes).
    • It's highly recommended to make vmix attach to the newly default device. vmix is OSSv4's software mixer and multiple programs will usually not be able to use the output at the same time if it's not attached. Since the default output was changed, vmix will have to be set to attach to the new output.
      In OSS 4.1 and above, add a "vmixctl attach" to be run after OSS is loaded. This can be done by editing the soundon.user file. It is also recommended to also add "vmix_no_autoattach=1" line to the $OSSLIBDIR/conf/osscore.conf file (so vmix won't use the old default too). "vmixctl attach" syntax looks like this:
      vmixctl attach /dev/oss/oss_sbxfi0/pcm0 /dev/oss/oss_sbxfi0/pcmin0
      The second and third argument represent output and input nodes for vmix to attach to, allowing full duplex when /dev/dsp is used. However, the third argument can be omitted in some cases. See "vmixctl" manpage for explanation.
      In OSS 4.0 you'll need to set vmix_masterdev in $OSSLIBDIR/conf/vmix.conf file.
    • Modern OSs put /dev on a ramdisk (i.e. it gets erased in boot), so we need to make sure the new correct setting remains. OSSv4.2 and above stores /dev/dsp setting in $OSSLIBDIR/etc/legacy_devices, so these should be saved automatically as long as OSS is shut down properly (You can run "sudo ossdevlinks" to save this manually).
    OSSv4 before version 4.2 requires editing the $OSSLIBDIR/soundon.user file again and placing the relinking command there. This would also work with newer OSSv4 versions.
  1. Alternative: If the default output is set to an onboard soundcard and you're using another card, you can just disable onboard audio in the BIOS, and it won't be seen by OSS.
  2. Alternative: $OSSLIBDIR/etc/installed_drivers influences the order of sound cards set by ossdetect. By removing other devices or moving the desired sound card to the first place, the default device can be modified. After the change, restart OSS and run "sudo ossdevlinks -v -r" and it will relink /dev/dsp for you.

OSSLIBDIR location

  • The OSSv4 root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is almost always /usr/lib/oss/.

Recording sound output of a program

There are two main scenarios here:

  1. Trying to record the entire desktop. Since more than one app may be playing, we want the total mixed output.
  2. Trying to record one specific app. This can be accomplished using solutions for the above (if nothing else is playing), but there are some more options here.
Recording total mixed output
  1. vmix loopback driver can record the mixed output of sound played. Set vmix_loopdevs to 1 (or 2) in $OSSLIBDIR/conf/osscore.conf, and restart OSS. Then record from the newly created loopback device ("ossinfo" command will display the device list, including the new device). Note that this is the mixed total of all sound played via vmix, not of a single program.
    ossrecord -s48000 -b16 -c2 -d/dev/oss/oss_hdaudio0/loop0 test.wav
    • Note that if vmixctl is used to (re)attach vmix, than 'ossdetect -d' is needed to be used after vmixctl to create the loop device.
    • Old OSSv4 versions (v4.0 before build 1016), used vmix.conf and not osscore.conf for this purpose, using the line "vmix1_numloops=1". Recording from vmix loopback didn't work in OSSv4.0 build 1016.
    • The recording program should expect the format, number of channels and sample rate to be the same as the ones used by vmix to "talk" to the device. The rate can be seen in the mixer (via ossxmix or ossmix) and set via the "sudo vmixctl rate" command. The number of channels is set via vmix0-channels control in the mixer (this is typically set to "Stereo"). The format is typically signed 16 bit. For example, if the above ossrecord line gives an error like: /dev/oss/oss_hdaudio0/loop0 doesn't support 2 channels (8), then vmix0-channels should be set to stereo.
  2. Alternative: Many drivers offer support for loopback recording via the hardware. This is typically done with the 'vol' mixer control. If this can be used as a recording source, than the current sound output will be recorded. Note that this is the mixed total of all sound played, not of a single program.
    ossmix vol.rec ON #sets 'vol' as default target, so any recording program uses it by default
    ossrecord blah.wav
    • Some drivers have a 'loopback' mixer control (instead of 'vol'), which offers similar functionality. This can be set by ossmix or ossxmix mixer control programs.
Recording output of a single program
  1. oss_userdev or oss_audioloop can also be used to record the output of a single program. Both the recorder and player will need to use the new node created by these drivers, and the recorder has to explicitly set up the appropriate format. oss_userdev can be used to serve multiple clients. See "oss_audioloop" and "oss_userdev" manpages for more information.
    • After manual loading of oss_userdev, a new mixer device is created. You'll have to run "sudo ossdetect -d" in order to be able to use it.
  2. Alternative: OSS wrappers can be used to record the output of a program. vsound is one such wrapper. (vsound doesn't handle output to /dev/oss/* device nodes, but all OSS-supporting programs are/can be easily made to output to /dev/dsp).
    vsound ossplay test.wav

Running a command immediately after OSS is loaded

The OSS startup script runs the file $OSSLIBDIR/soundon.user after OSS has loaded if the file has executable permissions. So the procedure is obvious:

  1. Edit the $OSSLIBDIR/soundon.user file and add that command before the "exit 0" line. If the file doesn't exist, you may create it as a shell script.
  2. Make sure that soundon.user has the executable bit set (it is not set by default).

One possible use of this is to have some volume controls set to a fixed level after OSS is started, regardless of their previous level last time OSS was run (by default, OSS restores the previous volume for all controls).

Swapping channels system-wide

  • In OSSv4.2 build2004 and above, this can be done using the 'vmixctl remap' command. e.g.:
sudo vmixctl remap /dev/dsp 2 1 #Swaps left and right
  • This requires vmix to be attached to the output used.
  • If you wish to do this every startup, see running a command after OSS is loaded.
  • The swap won't affect 'osstest' as it uses an uncommon interface by default, but just about every other program using the output will be affected. 'osstest -V' would also be affected by the remapping, and can be used for testing.
  • See 'vmixctl' manpage for more details.

Using multimedia keys with OSS

  1. First, we should check if the keys are recongnized by X11 or some other program. Run xev, and see if pressing the keys elicits a response.
    • If it does not, than we must make the keys be recognized by X11/WM/etc., before they can be used for anything. This is outside the scope of this wiki, but is documented at [1] and at [2]. Some WMs, once set up, will automatically connect the multimedia keys to appropriate functions.
  2. If/once the keys are recognized, does it work out of the box?
    • If not, it may be a function of old gstreamer version. Gnome uses gstremaer for this, but older gstreamer didn't support OSSv4. See Configuring_Applications_for_OSSv4#Gnome_Volume_Applet for a possible solution.
    • If the above does not work or is not applicable, we can connect the keys to external scripts which will perform the appropriate function (See examples below). The method to connect external scripts to keys is better described at [3] and at [4] again.
      • For example in KDE, you can start the "Control Center", enter "Regional & Accessibility" -> "Input Actions", click on "New Action" and make its type "Keyboard Shortcut -> Command/URL", and then set the multimedia key to launch the script. (Names can be different due to localizations).
External scripts which can control volume
mute.sh
#!/bin/sh
CTRL=vmix0-outvol
touch $HOME/.volume
VOLUME=$(cat $HOME/.volume)
CURRENT=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
if [ $CURRENT = "0.0" ]; then
      ossmix $CTRL $VOLUME
      > $HOME/.volume
else
      VOLUME=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
      ossmix $CTRL 0
      echo $VOLUME > $HOME/.volume
fi
ossvol

If you want the ability to mute and then unmute/increase volume at the same time the following script is one option. (This script relies on OSSv4.1 functionality - see note on ossmix below).

ossvol:

#!/bin/bash
#
# ossvol is a simple script to manage oss volume levels and muting.
#
# Script by: Daniel J Griffiths <ghost1227@archlinux.us>
# Configure stuff
VOLSTORE=~/.volume
CHANNEL="vmix0-outvol"
ARGUMENT=$2
# You shouldn't have to edit below here.
err() {
   echo "$1"
   exit 1
}
usage() {
   echo "usage: ossvol [option] [argument]"
   echo
   echo "Options:"
   echo "     -i, --increase - increase volume by [argument]"
   echo "     -d, --decrease - decrease volume by [argument]"
   echo "     -t, --toggle   - toggle mute on and off"
   echo "     -h, --help     - display this"
   exit
}
toggle() {
   if [ -f $VOLSTORE ]; then
       ossmix $CHANNEL `cat $VOLSTORE`
       rm $VOLSTORE
   else
       VOLUME=$(ossmix $CHANNEL | awk '{print $10}' | awk -F : '{print $1}')
       ossmix $CHANNEL 0
       echo $VOLUME > $VOLSTORE
   fi
}
increase() {
   if [ -f $VOLSTORE ]; then
       TMPVOL=`cat $VOLSTORE`
       NEWVOL=`expr $TMPVOL + $ARGUMENT`
       ossmix $CHANNEL +$NEWVOL
       rm $VOLSTORE
   else
       ossmix $CHANNEL +$ARGUMENT
   fi
}
decrease() {
   if [ -f $VOLSTORE ]; then
       TMPVOL=`cat $VOLSTORE`
       NEWVOL=`expr $TMPVOL - $ARGUMENT`
       ossmix $CHANNEL -- -$NEWVOL
       rm $VOLSTORE
   else
       ossmix $CHANNEL -- -$ARGUMENT
   fi
}
case "$1" in
   '-i'|'--increase')
   increase
   ;;
   '-d'|'--decrease')
   decrease
   ;;
   '-t'|'--toggle')
   toggle
   ;;
   |'-h'|'--help')
   usage
   ;;
   *)
   err "Unrecognized option \`$1', see ossvol --help"
   ;;
esac

OSSv4.1 includes an ossmix which allows you to change volume in a relative fashion: 'ossmix vmix0-vol -- -2' and 'ossmix vmix-vol +2'. The two scripts below can be used to have this functionality in OSSv4.0:

lowervolume.sh
 #!/bin/sh
 CTRL=vmix0-vol
 VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 VOL=$(echo $VOL | awk '{print $1-2}')
 ossmix -- $CTRL $VOL
raisevolume.sh
 #!/bin/sh
 CTRL=vmix0-vol
 VOL=$(ossmix | grep $CTRL | awk '{print $4}' | awk -F : '{print $1}')
 VOL=$(echo $VOL | awk '{print $1+2}')
 ossmix $CTRL $VOL

You may wish to modify a different mixer control than vmix0-vol. In that case, you will need to change the value of CTRL above.

ALSA Emulation

  • There are two main methods to achieve this:
  1. libasound2's pcm-oss plugin:
    • Easiest method, but will not work with all programs. It works by making libasound use OSS via the pcm-oss plugin.
    • First, install the pcm-oss plugin. It is included in the alsa-plugins distribution.
      • Debian: install libasound2-plugins package.
    • Make sure an ~/.asoundrc file exists. It should contain the lines below:
      pcm.!default
      {
        type oss
        device /dev/dsp
      }
      mixer.!default
      {
        type oss
        device /dev/dsp
      }
    
  2. libasound2's pulseaudio plugin:
    • Another easy method. Again, libasound must be set up to use Pulseaudio (which is done by default with many distros). Then Pulseaudio must be set up to use OSS.
  3. OSSv4 cuckoo module:
    • Harder, and will fail on most systems. It works by representing OSSv4 drivers as a soundcard to the ALSA modules, and supplying a "driver" for them.
    • Note that using pcm-oss conflicts with cuckoo - libasound needs to output to ALSA's device files, so rename ~/.asoundrc if you were using pcm-oss before doing this.
      Also, nearly all the commands below require root permissions.
      • First, we need to get the ALSA modules back:
        • Goto /lib/modules/$(uname -r)/, and extract the sound-preoss.tar.bz2 file.
        • We need to prune out the OSS emulation modules, since these might conflict with actual OSS, so run "rm -rf kernel/sound/core/oss".
      • Second, goto /usr/lib/oss/cuckoo, and run "make install".
      • You can now run "modprobe cuckoo", and test with "speaker-test" etc. whether this works.
      • To make this stick, we need to edit the startup script, so that it loads cuckoo after loading OSS. Edit $OSSLIBDIR/soundon.user, and add "modprobe cukoo" before "exit 0" line.
    • A general problem with ALSA emulation is that some programs probe for driver support in the order "ALSA, OSS". So programs that were using OSS by default may now try to use the emulation with possibly inferior results. So if there are problems after installation, make sure the program uses the OSS support if available rather than the emulation.