Difference between revisions of "Tips And Tricks"

From Open Sound System
Jump to: navigation, search
m (Changing the default sound output)
m (Changing the default sound output)
Line 13: Line 13:
 
# The typical method is to relink /dev/dsp to the desired /dev/oss/.../ device. e.g.
 
# The typical method is to relink /dev/dsp to the desired /dev/oss/.../ device. e.g.
 
#::  ln -sf /dev/oss/oss_sbxfi0/pcm0 /dev/dsp
 
#::  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).
+
#: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). If OSS insists on recreating /dev/dsp, simply add the appropriate linking command (typically ln -sf /dev/oss/.../ /dev/dsp) to a file $OSSLIBDIR/soundon.user (You will probably have to create it and give executable permissions). In OSS 4.1, it's best to also add a "vmixctl attach /dev/dsp" command in the file to make sure vmix is attached.
If OSS insists on recreating /dev/dsp, simply add the appropriate linking command (typically ln -sf /dev/oss/.../ /dev/dsp) to a file $OSSLIBDIR/soundon.user (You will probably have to create it and give executable permissions). In OSS 4.1, it's best to also add a "vmixctl attach /dev/dsp" command in the file to make sure vmix is attached.
+
 
# 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.
 
# 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.
 
#: The root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is typically /usr/lib/oss/.
 
#: The root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is typically /usr/lib/oss/.

Revision as of 20:36, 26 October 2008

Starting ossxmix minimized to tray on desktop startup

The '-b' option starts ossxmix in the background - minimized to tray if tray support is compiled in, iconfied window if not. The '-S' option prevents ossxmix from trying to use a system tray. ossxmix -Sb' will always start an iconified window.

  1. KDE: create a desktop shortcut in ~/.kde/Autostart with the command 'ossxmix -b'.
    Alternative: create a desktop shortcut in the same place, with the command "ossxmix -Sb'. Go to Applications->"Advanced options" and select "Place in system tray".
  2. Gnome: go to "Control center"->"Session"->"Startup Programs" and add "ossxmix -b".
    Note that the quoted names can be slightly different on some systems due to localizations.
  3. X11 in general: edit the Xsession file. Make sure the tray program runs before ossxmix, or use the '-S' switch as well.
  4. See [1] for info on other environments.

Changing the default sound output

  1. The typical method is to relink /dev/dsp to the desired /dev/oss/.../ device. e.g.
    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). If OSS insists on recreating /dev/dsp, simply add the appropriate linking command (typically ln -sf /dev/oss/.../ /dev/dsp) to a file $OSSLIBDIR/soundon.user (You will probably have to create it and give executable permissions). In OSS 4.1, it's best to also add a "vmixctl attach /dev/dsp" command in the file to make sure vmix is attached.
  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.
    The root directory $OSSLIBDIR can be found by checking /etc/oss.conf. It is typically /usr/lib/oss/.

Recording sound output of a program

There are several methods to achieve this:

  1. Many drivers offer a '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.
    ossrecord -ivol blah.wav
    • Some drivers have a 'loopback' mixer control, which offers similar functionality.
  2. 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
  3. (This method doesn't work in build 1016 or in 4.1) vmix loopback driver can record the output of a program. Set vmix1_numloops to 1 (or more) in vmix.conf, and make the program output to the newly created /dev/oss/vmix0/loop0 device (after restaring OSS). Then record from that device. e.g.
    ossrecord -s48000 -b16 -c2 -d/dev/oss/vmix0/loop0 test.wav
    • Perhaps audioloop driver can probably be used as well for this purpose? Man page says it needs a "server" and a "client", so if it can be used for this, it's only for a single program.

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 [2] and at [3]. 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 [4] and at [5] 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-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.

OSS4.1 allows you to use ossmix directly instead of the first two scripts below: 'ossmix vmix0-vol -- -2' and 'ossmix vmix-vol +2'. The scripts are however neccesary for 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.