** If you bought a new card to a machine already using OSS, OSS will still try to use the old drivers. So in order to make OSS rescan the computer, run "sudo ossdetect -v". Then restart OSS and test again.

*Are the outputs muted in the mixer?

*Are the outputs muted in the mixer?

+

*Do the device nodes (/dev/dsp, /dev/oss directory, etc.) exist (osstest should complain if they don't)? If not, restarting OSS would probably create them. However, the following two commands should create them without need to restart:

+

*: sudo ossdevlinks -r -v

+

*: sudo ossdetect -d -v

*Is the default output (the one linked to /dev/dsp) the one connected / outputting sound in osstest? If not, see [[Tips_And_Tricks#Changing_the_default_sound_output | here]] how to change that.

*Is the default output (the one linked to /dev/dsp) the one connected / outputting sound in osstest? If not, see [[Tips_And_Tricks#Changing_the_default_sound_output | here]] how to change that.

*HDAudio: Are the jacks detected by OSS as output, actually the jacks connected to the speaker?

*HDAudio: Are the jacks detected by OSS as output, actually the jacks connected to the speaker?

−

*Ich: Setting ac97_amplifier to 0 in $OSSLIBDIR/conf/osscore.conf helped on a Gateway 4542GP notebook.

+

*HDAudio: Some of these devices needs to be set up in the mixer before they can play sound. Run "osstest -l" in the background and "ossxmix" in the foreground. Change settings in the mixer until you hear a sound or exhaust all settings. A similar technique can be used for testing recording (using "ossrecord - | ossplay -" instead of osstest).

−

** $OSSLIBDIR is typically /usr/lib/oss, and can be determined exactly by the contents of /etc/oss.conf.

+

*Ich: Some computers have an inverted external amplifier settings, so setting ac97_amplifier to 0 in $OSSLIBDIR/conf/osscore.conf would help. Gateway notebooks (Gateway 4542GP, 4028GZ, 7326GZ) in particular often have this problem.

+

** $OSSLIBDIR is almost always /usr/lib/oss, and can be determined exactly by the contents of /etc/oss.conf.

*Recording can be tested by using the "ossrecord" program supplied with OSS. "ossrecord - | ossplay -" can be used to set up an echo useful for testing.

+

*Make sure the mic or cable used for input is connected and functional.

+

*Check that the proper recording source is set as the input. Some typical cases:

+

** If the driver is oss_ich, you may have to check the "rec" button for the proper input

+

** With oss_audigyls, there's a combobox to select between "mic"/"aux"/"line" inputs.

+

** With oss_hdaudio, "input-mix" or "select" or "rec1" comboboxes might do this, and the mode of the jack where the input is at should be set to "input". oss_hdaudio mixer is complicated and not entirely consistent between different codecs/devices. You may have to experiment with it.

+

*Ensure that recording volume is not muted. Note that recording volume is often ''not'' the volume of the jack/port where the input is at (these typically set passthrough volume).

+

** For example, in AC97-based devices, recording volume is typically set by "igain" slider rather than "mic" or "line-in" etc.

+

*If there are several input nodes (this is visible in ossinfo output), you may have to use a non-default one. e.g. "ossrecord -d/dev/oss/oss_hdaudio0/pcmin1" etc.

== I hear noises! ==

== I hear noises! ==

−

*Many soundcards' hardware requires output mixers be set to less than maximum (even down to 60% with a few cards).

+

*Does this happen only with a particular program? If so, it might be trying to force a too small fragment size or using OSS indirectly (e.g. via a sound server like esd). The [[Configuring_Applications_for_OSSv4 | Configuring Applications for OSSv4]] page has tips on how to reconfigure some programs to use OSS properly.

−

*Set vmix0-src to an higher setting using a mixer program.

+

*Many soundcard's hardware requires output mixers be set to less than maximum (even down to 60% with a few cards).

+

*Set vmix0-src to an higher setting using a mixer program like ossxmix.

+

*Check if there's an input mixer control which is unmuted in the mixer, and try muting it. An unmuted input may make noise if it is unconnected to anything or if the input cable is noisy.

+

*Check with osstest command whether there's another output node which doesn't have noise. If there is such a node, you may wish to [[Tips_And_Tricks#Changing_the_default_sound_output| make it the default output]].

*Is the cable from the soundcard to the speakers connected correctly? Could it be too long?

*Is the cable from the soundcard to the speakers connected correctly? Could it be too long?

−

*Build and use OSS using the source from the public hg repository, perhaps a newer version will work better.

== I can't get multiple sound clients to play on the same device! ==

== I can't get multiple sound clients to play on the same device! ==

−

*multiple clients to same device node aren't supported on 4front's OSS for FreeBSD. It instead splits the mixing to separate devices: /dev/dsp1, /dev/dsp2, etc. Either set programs to use separate devices, or use a sound server like aRts, esd, etc.

+

*OSSv4.0 for the FreeBSD platform doesn't support multiple clients to same device node on /dev/dsp device node (OSSv4.0 does support this on other platforms like Linux). It instead splits the mixing to separate devices: /dev/dsp1, /dev/dsp2, etc. Either set programs to use separate devices, or use a sound server like aRts, esd, etc., or upgrade to v4.1 which supports multiple clients on FreeBSD 7.1 and up.

−

*Is vmix loaded?

+

*Is vmix loaded and attached to the device? (Check if 'ossinfo -v3' shows more than one engine for the output device).

−

** If yes, Is vmix attached to the default output device? (Check if 'ossinfo -v3' shows more than one engine for the default output device).

+

** In OSS 4.0, (Doesn't apply to build 1016:) If vmix is not attached, make sure vmix1_masterdev in $OSSLIBDIR/conf/vmix.conf is set to the output device's device index (this can be determined via 'ossinfo -a'). ($OSSLIBDIR is typically /usr/lib/oss).

** In OSS 4.0, (Doesn't apply to build 1016:) If vmix is not attached, make sure vmix1_masterdev in $OSSLIBDIR/conf/vmix.conf is set to the output device's device index (this can be determined via 'ossinfo -a'). ($OSSLIBDIR is typically /usr/lib/oss).

*Some configurations require more than one cable connected to the speaker set. Make sure that as many cables as required are connected.

*Some configurations require more than one cable connected to the speaker set. Make sure that as many cables as required are connected.

−

*Some devices have the multich output at a different device node than the regular one, use /dev/dsp_multich rather than /dev/dsp as /dev/dsp_multich is always linked to the correct device. In the case of Dolby digital/AC3, /dev/dsp_ac3 is the best device instead of /dev/dsp_multich.

+

*Some devices have the multich output at a different device node than the regular one, use /dev/dsp_multich rather than /dev/dsp as /dev/dsp_multich is always linked to the correct device. In the case of Dolby digital/AC3, /dev/dsp_ac3 is the best device instead of /dev/dsp_multich. It is possible that the node /dev/dsp_multich is symlinked to doesn't have vmix attached, so multiple clients won't play. This can be fixed using the "vmixctl" command as in the tip above.

−

*Some devices require changing settings in the mixer (e.g. by 'ossmix' or 'ossxmix') to work.

+

* In recent OSS versions (4.1 and OSS 4.0 build 1016 and above), vmix0-channels needs to be set to "Multich" in the mixer if vmix is attached to the multichannel output (vmix being attached can be checked with 'ossinfo' output. If you don't know what this means, just test with and without this setting).

** In versions of OSS before 4.0 build 1016, set vmix1_multich=1 in $OSSLIBDIR/conf/vmix.conf ($OSSLIBDIR is typically /usr/lib/oss).

−

** In 4.1, set vmix0-channels to "Multich" in the mixer.*sblive/audigy devices may require use of the sblive_digital_din (or audigy_digital_din) option in the device configuration file - see driver manpage.

+

*Some devices require changing settings in the mixer (e.g. by 'ossmix' or 'ossxmix') to work in this mode.

+

*sblive/audigy devices may require use of the sblive_digital_din (or audigy_digital_din) option in the device configuration file - see driver manpage (e.g. "man oss_audigyls").

I can't hear any sound!

Did OSS load at all? Run the command to examine loaded modules specific to your OS (lsmod, kldstat, etc.) to find out.

Does osstest work?

Is your card recognized by OSS? Check "ossinfo" output.

If you bought a new card to a machine already using OSS, OSS will still try to use the old drivers. So in order to make OSS rescan the computer, run "sudo ossdetect -v". Then restart OSS and test again.

Are the outputs muted in the mixer?

Do the device nodes (/dev/dsp, /dev/oss directory, etc.) exist (osstest should complain if they don't)? If not, restarting OSS would probably create them. However, the following two commands should create them without need to restart:

sudo ossdevlinks -r -v

sudo ossdetect -d -v

Is the default output (the one linked to /dev/dsp) the one connected / outputting sound in osstest? If not, see here how to change that.

HDAudio: Are the jacks detected by OSS as output, actually the jacks connected to the speaker?

HDAudio: Some of these devices needs to be set up in the mixer before they can play sound. Run "osstest -l" in the background and "ossxmix" in the foreground. Change settings in the mixer until you hear a sound or exhaust all settings. A similar technique can be used for testing recording (using "ossrecord - | ossplay -" instead of osstest).

Ich: Some computers have an inverted external amplifier settings, so setting ac97_amplifier to 0 in $OSSLIBDIR/conf/osscore.conf would help. Gateway notebooks (Gateway 4542GP, 4028GZ, 7326GZ) in particular often have this problem.

$OSSLIBDIR is almost always /usr/lib/oss, and can be determined exactly by the contents of /etc/oss.conf.

Is this an hardware issue?

Are the speakers muted?

Is the soundcard connected correctly to the speakers?

Do other drivers available for your OS (e.g. ALSA for Linux, FreeBSD native) work?

I can't record!

Recording can be tested by using the "ossrecord" program supplied with OSS. "ossrecord - | ossplay -" can be used to set up an echo useful for testing.

Make sure the mic or cable used for input is connected and functional.

Check that the proper recording source is set as the input. Some typical cases:

If the driver is oss_ich, you may have to check the "rec" button for the proper input

With oss_audigyls, there's a combobox to select between "mic"/"aux"/"line" inputs.

With oss_hdaudio, "input-mix" or "select" or "rec1" comboboxes might do this, and the mode of the jack where the input is at should be set to "input". oss_hdaudio mixer is complicated and not entirely consistent between different codecs/devices. You may have to experiment with it.

Ensure that recording volume is not muted. Note that recording volume is often not the volume of the jack/port where the input is at (these typically set passthrough volume).

For example, in AC97-based devices, recording volume is typically set by "igain" slider rather than "mic" or "line-in" etc.

If there are several input nodes (this is visible in ossinfo output), you may have to use a non-default one. e.g. "ossrecord -d/dev/oss/oss_hdaudio0/pcmin1" etc.

I hear noises!

Does this happen only with a particular program? If so, it might be trying to force a too small fragment size or using OSS indirectly (e.g. via a sound server like esd). The Configuring Applications for OSSv4 page has tips on how to reconfigure some programs to use OSS properly.

Many soundcard's hardware requires output mixers be set to less than maximum (even down to 60% with a few cards).

Set vmix0-src to an higher setting using a mixer program like ossxmix.

Check if there's an input mixer control which is unmuted in the mixer, and try muting it. An unmuted input may make noise if it is unconnected to anything or if the input cable is noisy.

Check with osstest command whether there's another output node which doesn't have noise. If there is such a node, you may wish to make it the default output.

Is the cable from the soundcard to the speakers connected correctly? Could it be too long?

I can't get multiple sound clients to play on the same device!

OSSv4.0 for the FreeBSD platform doesn't support multiple clients to same device node on /dev/dsp device node (OSSv4.0 does support this on other platforms like Linux). It instead splits the mixing to separate devices: /dev/dsp1, /dev/dsp2, etc. Either set programs to use separate devices, or use a sound server like aRts, esd, etc., or upgrade to v4.1 which supports multiple clients on FreeBSD 7.1 and up.

Is vmix loaded and attached to the device? (Check if 'ossinfo -v3' shows more than one engine for the output device).

In OSS 4.0, (Doesn't apply to build 1016:) If vmix is not attached, make sure vmix1_masterdev in $OSSLIBDIR/conf/vmix.conf is set to the output device's device index (this can be determined via 'ossinfo -a'). ($OSSLIBDIR is typically /usr/lib/oss).

In OSS 4.1, 'vmixctl' command is used instead of vmix.conf (requires root permissions).

Are the vmix controls in ossxmix unmuted?

I can't get multichannel/5.1 output to play!

Some configurations require more than one cable connected to the speaker set. Make sure that as many cables as required are connected.

Some devices have the multich output at a different device node than the regular one, use /dev/dsp_multich rather than /dev/dsp as /dev/dsp_multich is always linked to the correct device. In the case of Dolby digital/AC3, /dev/dsp_ac3 is the best device instead of /dev/dsp_multich. It is possible that the node /dev/dsp_multich is symlinked to doesn't have vmix attached, so multiple clients won't play. This can be fixed using the "vmixctl" command as in the tip above.

In recent OSS versions (4.1 and OSS 4.0 build 1016 and above), vmix0-channels needs to be set to "Multich" in the mixer if vmix is attached to the multichannel output (vmix being attached can be checked with 'ossinfo' output. If you don't know what this means, just test with and without this setting).

In versions of OSS before 4.0 build 1016, set vmix1_multich=1 in $OSSLIBDIR/conf/vmix.conf ($OSSLIBDIR is typically /usr/lib/oss).

Some devices require changing settings in the mixer (e.g. by 'ossmix' or 'ossxmix') to work in this mode.

sblive/audigy devices may require use of the sblive_digital_din (or audigy_digital_din) option in the device configuration file - see driver manpage (e.g. "man oss_audigyls").