Thanks so much for looking at this! Here what I found:
(Not sure if it's related to the problem, but I noticed that azalia1 attaches
to "unknown product..." in dmesg.)
> To confirm this, the next time this happens, after mpv terminates,
> could you run in one terminal:
>
> cat /dev/zero >/dev/audio0
>
> and in another run:
>
> audioctl
> sleep 1
> audioctl
While 'cat /dev/zero > /dev/audio0' is running in one tmux window, the audioctl
commands return:
$ audioctl
name=azalia1
mode=play
pause=0
active=1
nblks=8
blksz=960
rate=48000
encoding=s16le
play.channels=2
play.bytes=0
play.errors=0
record.channels=2
record.bytes=0
record.errors=0
$ sleep 1
$ audioctl
name=azalia1
mode=play
pause=0
active=1
nblks=8
blksz=960
rate=48000
encoding=s16le
play.channels=2
play.bytes=0
play.errors=0
record.channels=2
record.bytes=0
record.errors=0
$
> to confirm that all counters are frozen. As we're at it run:
>
> vmstat -i | grep azalia
> sleep 1
> vmstat -i | grep azalia
>
> to confirm the interrupts count is not increasing.
$ vmstat -i | grep azalia
irq176/azalia1 5714 14
$ sleep 1
$ vmstat -i | grep azalia
irq176/azalia1 5714 14
$
> It's unclear how this could happen.
>
> - Do you remember if this stopped working recently or
> the problem is there since you got the machine?
I got this desktop PC in July 2017. Pretty sure it's been there since the
beginning or at least shortly thereafter. Note that I changed the motherboard
in October from an ASRock A320M to this MSI X370 Gaming Plus and the problem
persisted through the motherboard (and therefore soundcard change).
Also note that I did not observe anything of the kind on this machine when
booted into Windows or Ubuntu.
> - Does the problem occur in mpv right after you change the volume?
The way I trigger it is by repeatedly changing the volume. I tap volume up/
volume down shortcuts about a dozen times in quick succession and then the bug
occurs pretty reliably when mpv is running (or video playback in a browser -
usually firefox in my case).
> What happens if you never change the volume?
The sound stops working eventually (which can be after hours of playback) if
given enough time without me doing any such volume changes. I can't identify
any specific user activity from my side that is associated with it in that
case, but the same looping for a few seconds and inability to recover until a
reboot happens. The time until this happens seems variable. Sometimes 10
minutes, sometimes hours. I haven't found a particular spot in a sound stream
that would reliably trigger it.
> What happens if
> you make cwm run another command instead of mixerctl (ex. ls /)
With the same key combo set to 'ls /' in cwmrc, I couldn't trigger the problem.
But I triggered it when repeatedly entering mixerctl outputs.master=+5 in the
terminal (without going through cwm or a key combo).
> - Does the problem occur if no video is involved? ex. when you
> play a long audio file (or "aucat -i /dev/zero") and use
> the cwm volume keys ?
I didn't observe it yesterday with mocp when trying to provoke, but maybe it
just requires more mixerctl activity/interference because I was able to trigger
it while 'aucat -i /dev/zero'. Here the terminal output from aucat and from
sndiod -dd that I was running at the same time to see what happens:
tmux window 1:
$ aucat -i /dev/zero
default: audio device gone, stopping
$
tmux window 2:
$ doas sndio -dd
snd0.default: rec=0:1 play=0:1 vol=23170 dup
snd0: 48000Hz, s16le, play 0:1, rec 0:1, 8 blocks of 960 frames
aucat0: 48000Hz, s16le, play 0:1, 10 blocks of 960 frames
snd0: device started
aucat0: attached at -7680, delta = 0
snd0: watchdog timeout
Thanks again. Let me know if additional information/testing can help to
troubleshoot this!
