Solved Problem with sound FreeBSD12.1p10

Solution: Add dev.hdac.0.polling=1 / dev.hdac.1.polling=1 to /etc/sysctl.conf and restart the host. The issue is caused by a missed interrupt signal. Re-configuring the sound system to poll instead of waiting on an interrupt that never arrives avoids that problem. See below for the side effects.

OP

I am having problems with the sound handling on my workstation. This originally evidenced itself in the failure to play videos on youtube, and subsequently on mplayer. However, immediately after booting the system, not a power down just a shutdown -r now, youtube videos can play. Several in fact. When I return to youtube to view other videos they will not play. The only way to regain the ability is to restart the system. This problem was diagnosed as being caused by the inability of the video stream to sync with the sound feed.

I have gone though the setup procedure for the sound system in the FreeBSD handbook. This is what I see:

Code:
[root@vhost01 ~ (master)]# dmesg | grep pcm
pcm0: <NVIDIA (0x0051) (HDMI/DP 8ch)> at nid 4 on hdaa0
pcm1: <NVIDIA (0x0051) (HDMI/DP 8ch)> at nid 5 on hdaa0
pcm2: <Realtek ALC892 (Rear Analog 5.1/2.0)> at nid 20,22,21 and 24,26 on hdaa1
pcm3: <Realtek ALC892 (Front Analog)> at nid 27 and 25 on hdaa1
pcm4: <Realtek ALC892 (Rear Digital)> at nid 30 on hdaa1
pcm2: chn_write(): pcm2:virtual:dsp2.vp1: play interrupt timeout, channel dead
pcm0: <NVIDIA (0x0051) (HDMI/DP 8ch)> at nid 4 on hdaa0
pcm1: <NVIDIA (0x0051) (HDMI/DP 8ch)> at nid 5 on hdaa0
pcm2: <Realtek ALC892 (Rear Analog 5.1/2.0)> at nid 20,22,21 and 24,26 on hdaa1
pcm3: <Realtek ALC892 (Front Analog)> at nid 27 and 25 on hdaa1
pcm4: <Realtek ALC892 (Rear Digital)> at nid 30 on hdaa1

The sound preferences show that /dev/dsp2 is the configured (stereo) source. This is confirmed by:
Code:
[root@vhost01 ~ (master)]# cat /dev/sndstat
Installed devices:
pcm0: <NVIDIA (0x0051) (HDMI/DP 8ch)> (play)
pcm1: <NVIDIA (0x0051) (HDMI/DP 8ch)> (play)
pcm2: <Realtek ALC892 (Rear Analog 5.1/2.0)> (play/rec) default
pcm3: <Realtek ALC892 (Front Analog)> (play/rec)
pcm4: <Realtek ALC892 (Rear Digital)> (play)
No devices installed from userspace.

Sysctl also shows dsp2 as the sound device:
Code:
[root@vhost01 ~ (master)]# sysctl hw.snd.default_unit
hw.snd.default_unit: 2

Mixer shows this:
Code:
[root@vhost01 ~ (master)]# mixer
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to  74:74
Mixer line     is currently set to   1:1
Mixer mic      is currently set to  67:67
Mixer mix      is currently set to  74:74
Mixer rec      is currently set to  35:35
Mixer igain    is currently set to  54:54
Mixer ogain    is currently set to 100:100
Recording source: mic

Visual inspection confirms that the jacks are inserted in the rear sockets and the fact that one can get both video and audio shortly after restarting the system also confirms that the physical connections are correct and working.

I notice that dmesg reports pcm2: chn_write(): pcm2:virtual:dsp2.vp1: play interrupt timeout, channel dead which seems a likely suspect as being the cause of these difficulties. The problem then to to discover what is causing this and how to correct it.

Advice on this matter is welcome.
 
I notice that dmesg reports pcm2: chn_write(): pcm2:virtual:dsp2.vp1: play interrupt timeout, channel dead which seems a likely suspect as being the cause of these difficulties. The problem then to to discover what is causing this and how to correct it.

Try sysctl(8) variable dev.hdac.1.polling=1:

 
That change appears to have worked. I had tried that before but I had already encountered the problem with sound when I used sysctl to set polling on. Doing so appeared to have no effect since the channel was already stalled.

After rereading the solution I added the settings to sysctl.conf and restarted the host. Since then the problem seems to have disappeared.

Thanks
 
There is a caveat to the solution provided above. The sound is no longer controlled by an application that uses sound. In the case of Firefox the application initially sets the volumn to zero. The only way of changing this is through the Application tab in the sound preferences window. Neither the application nor the desktop volume sliders have any effect.

In the case of MPlayer the volume is initially set to max and there is no entry in the Applications tab of the sound preferences window. The MPlayer sound slider moves but has no effect, which is the same behaviour observed for Firefox. However, the desktop volume slider does work which is a little more convenient.
 
Solution: Add dev.hdac.0.polling=1
I don't think you need to set dev.hdac.0.polling=1.
dev.hdac.0 is, if I'm not mistaken, the NVIDIA sound device: sysctl -a | grep hdac.0.%desc .

Also have a look at this posting:
 
Back
Top