Bug 42478

Created attachment 53005 [details]
Output of pulseaudio -vvvvv

I produced a log output of pulseaudio, maybe it is useful. The log contains the following actions:

- start pulseaudio (nothing is playing)
- start VLC and begin playback (no sound from speakers)
- change output configuration from 5.1 to stereo in pavucontrol (sound is now audible)
- change output configuration from stereo back to 5.1 in pavucontrol (sound is still audible)
- quit VLC (nothing is playing anymore)
- start VLC and begin playback (again no sound from speakers)

Could you post the output of alsa-info[1] from when the output is working and when it is not?

[1] http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh

Created attachment 58470 [details]
alsa-info when running PA without module-suspend-on-idle (WORKING sound)

Created attachment 58471 [details]
alsa-info when running PA with module-suspend-on-idle (NON-WORKING sound)

The alsa-info from when sound is not working was collected after starting pulseaudio with module-suspend-on-idle, playing a sound (verifying its working), waiting for the suspend module to trigger, and playing a sound again (verifying it is not working).
So this shows the suspended state.

This might be a long shot, and I'm not completely sure, but I suspect this might be bad position reporting from the hardware, see

https://wiki.ubuntu.com/Audio/PositionReporting

Neither using the module parameter for snd_hda_intel nor disabling PA's timer scheduling worked for me.

Note that I didn't reboot my computer for these tests. Instead I just unloaded the snd_hda_intel module and loaded it again with the position_fix parameter specified on the modprobe command line. If this is not enough, I can do it with reboots, but this machine is used remotely by others as well, so I try to avoid that.

Hmm, I just had a look in your alsa-info as well, and it shows entries like this:

[1788814.086727] [drm:drm_detect_monitor_audio], Monitor has basic audio support
[1788814.086733] [drm:output_poll_execute], [CONNECTOR:14:HDMI-A-2] status updated from 1 to 1
[1788814.087245] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e

If you get strange entries in your dmesg when audio stops working, it looks like a kernel/hardware bug to me. Or did you repeatedly plug in and unplug your hdmi cable?

Yes, I switch a lot between two devices connected via HDMI (my monitor, which is connected via a HDMI-DVI adapter, and my receiver). So the log entries might result from this.

For this problem I tested only the connection to the receiver. So I plugged in the receiver, verified the sound is working and then waited for the suspend timeout, after which the sound is not working.

If required, I can reproduce the problem and provide dmesg output, but this will take a few days as I'm currently out of country. However, although I am not sure, I guess I looked into the dmesg output when having the problem for the first time, and didn't find anything interesting.

This looks very much like an ALSA driver issue, so I'm dropping it as a 2.0 blocker.

I'm seeing a similar issue with a similar setup.  I've got a media center connected to a receiver via HDMI.  Sometimes when I'm playing audio and power-cycle devices in the chain (TV, receiver, etc), pulse will stop playing audio.  I don't get any errors or anything, and issuing pulseaudio -k will bring it all back.

I tried commenting out the module-suspend-on-idle module.  It seemed to work at first, but I eventually got into a state where PA applications complained about not being able to play back, and audio went silent.

I think this could be an ALSA issue, but it's quite difficult to debug.  Has anyone else come up with a solution to this problem?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/147.