Synopsis #
An audio failure can occur at several layers: the kernel did not attach a sound device, the wrong pcm unit became the default, a mixer channel is muted, the login cannot open the device, or an application selected another output or input. Diagnose those layers in order.
Several audio devices are normal on systems with analog sound, an internal microphone, USB audio, and HDMI or DisplayPort outputs. Do not load every sound driver or add device hints merely because pcm0 is not the desired output.
Confirm kernel detection #
List attached audio devices and their boot messages:
$ cat /dev/sndstat
$ dmesg | grep pcm
$ kldstat | grep snd
/dev/sndstat identifies each pcm unit and marks the current default. The dmesg output helps distinguish analog, microphone, USB, HDMI, and DisplayPort paths.
If no pcm unit appears, identify the audio controller first:
$ pciconf -lv | grep -A4 -B3 multimedia
Consult sound(4)
and the manual page for the attached controller. As a temporary diagnostic, the documented metadriver can load available sound drivers:
# kldload snd_driver
$ cat /dev/sndstat
If this discovers the device, identify the specific driver and configure that driver rather than making snd_driver the permanent first choice. Loading every sound driver increases ambiguity and is not evidence that the hardware is fully working.
Check the selected default #
Read the default unit and compare it with /dev/sndstat:
$ sysctl hw.snd.default_unit
$ cat /dev/sndstat
Graphics devices often attach several HDMI or DisplayPort outputs before the analog codec. To test a different known unit temporarily, substitute its pcm number:
# sysctl hw.snd.default_unit=4
Repeat the application test. If the unit is correct, make the tested sysctl persistent through /etc/sysctl.conf as described in the persistent settings guide
. Do not persist a unit number until it has been checked after reboot; USB attachment order can change.
An application can select a non-default device explicitly. Inspect its audio settings even when the base-system default is correct.
Inspect mixer state #
Display the controls for the default mixer:
$ mixer
Check playback volume and mute state for output problems. For microphone problems, check the recording source, recording level, and mute state. Control names vary by driver and codec, so do not copy a mixer channel name that the local mixer output does not contain.
Change one control at a time with the syntax documented by mixer(8)
, then repeat the same playback or recording test. A desktop volume widget can add another policy layer; establish whether the base mixer works before resetting desktop audio configuration.
Check device access #
Inspect the default and numbered DSP nodes:
$ ls -l /dev/dsp /dev/dsp* /dev/mixer /dev/mixer*
$ id
Do not solve an access error with mode 0666. Determine which service, group, or application owns the expected access policy. The USB permissions guide
explains why hotplug device modes must be scoped and persistent.
Use fstat to see which processes already hold sound devices:
# fstat | grep '/dev/dsp'
This can reveal an audio server or application using a device unexpectedly. It does not by itself mean that concurrent access is impossible; FreeBSD virtual channels can mix multiple streams.
Separate application failures #
Test in increasing order of complexity:
- A base-system or small local playback test.
- The desktop’s audio control and a local media player.
- A browser playing ordinary unprotected media.
- Microphone recording in a local application.
- Browser microphone permission and the meeting site.
If local audio works but a browser does not, preserve the browser’s terminal output and inspect its selected device and site permission. Reinstalling the kernel sound driver is unlikely to correct a site-level permission denial.
After suspend and resume, repeat /dev/sndstat, the default-unit check, and a local test. A device that disappears only after resume belongs in the laptop resume evidence, not in a generic mixer workaround.
Avoid speculative device hints #
Audio codec pin assignments can be changed through device.hints, but the values are machine-specific and an incorrect assignment can remove working paths. Collect verbose driver information and consult snd_hda(4) before changing pins. Keep console access and a copy of the previous file.
Do not publish another machine’s nid, cad, or pin configuration as a general fix.