Hardware configuration: Gigabyte GA-970A-D3 motherboard with VIA VT2020 audio chipset. Stereo speakers connected to rear panel line-out, and headphones connected to front panel headphone jack. Expected behaviour: Sound should play out of the headphones, and speakers muted. Actual behaviour: When the headphones are plugged in while the OS is live, they are detected and sound is played through them. However, if the computer is suspended or shut down with the headphones still connected, and then the computer is turned back on, the headphones are no longer available as an output device. Workaround: Adding "options snd-hda-intel jackpoll_ms=400" to /etc/modprobe.d/alsa-base.conf fixes the behaviour. Bug was previously reported here (and subsequently confirmed to be an ALSA issue): https://bugs.freedesktop.org/show_bug.cgi?id=90608 Raymond (see comments #13, 17 from link above) suggests that the jackpoll_ms option was meant for the VT1708 chipset, which doesn't support unsolicited events. However, the VT2020 supports unsolicited events.
ports: analog-output-lineout: Line Out (priority 9900, latency offset 0 usec, available: yes) properties: analog-output-headphones: Headphones (priority 9000, latency offset 0 usec, available: yes) properties: device.icon_name = "audio-headphones" active port: <analog-output-lineout> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/paths/analog-output-lineout.conf?id=5598923b8e64de873a417b512d709c5674f3a96d alsa-mixer: Make line out path unavailable when "Front Headphone" is plugged in diff --git a/src/modules/alsa/mixer/paths/analog-output-lineout.conf b/src/modules/alsa/mixer/paths/analog-output-lineout.conf index 53ee2f4..68f444a 100644 --- a/src/modules/alsa/mixer/paths/analog-output-lineout.conf +++ b/src/modules/alsa/mixer/paths/analog-output-lineout.conf @@ -29,6 +29,10 @@ required-any = any state.plugged = no state.unplugged = unknown +[Jack Front Headphone] +state.plugged = no +state.unplugged = unknown + [Jack Line Out Front] required-any = any have you applied pulseaudio patch since availability of line out should be no when headphone is plugged ?
when availability of line out is yes, headphone will be swtched off by this patch http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/mixer/paths/analog-output-lineout.conf?id=9d0a5b5cb7ea3adc1b548a6e1e953ee20835e6b6 alsa-mixer: Mute headphones and speakers on line out path When line out path is active, we want to mute speakers for obvious reasons, and headphones to avoid volume spikes. --- a/src/modules/alsa/mixer/paths/analog-output-lineout.conf +++ b/src/modules/alsa/mixer/paths/analog-output-lineout.conf @@ -102,23 +102,22 @@ volume = off switch = off required-any = any -; This profile path is intended to control the default output, not the -; headphones. But it should not hurt if we leave the headphone jack -; enabled nonetheless. +; This profile path is intended to control line out, let's mute headphones +; else there will be a spike when plugging in headphones [Element Headphone] -switch = mute -volume = zero +switch = off +volume = off [Element Headphone2] -switch = mute -volume = zero +switch = off +volume = off [Element Speaker] -switch = mute +switch = off volume = off [Element Desktop Speaker] -switch = mute +switch = off volume = off [Element Front]
I'm running pulseaudio from git (I switched over before submitting the bug report on freedesktop), so I do have the patch that you referenced above.
Please give alsa-info.sh outputs before and after suspend. Run the script with --no-upload option and attach to bugzilla. Try both with and without jackpoll_ms option.
Created attachment 177891 [details] alsa-info.sh output before/after suspend I've attached the output, and also the diffs (Raymond had previously asked for the same thing, so I already had them).
Thanks. Then try to detect the jack manually via hda-verb (as root), e.g. # hda-verb /dev/snd/hwC0D0 0x28 GET_PIN_SENSE 0 before and after suspend. Does it return avalue with bit 31 set when the headphone jack is plugged? Also, try to enable tracing and gather verbs while suspend/resume. # echo 1 > /sys/kernel/debug/tracing/events/hda/enable ... do suspend and resume... # cat /sys/kernel/debug/tracing/trace > trace.log # echo 0 > /sys/kernel/debug/tracing/events/hda/enable
Created attachment 177941 [details] kernel event trace I get the same return value, with bit 31 set, both before and after suspend: root@furkan-pc:~# hda-verb /dev/snd/hwC0D0 0x28 GET_PIN_SENSE 0 nid = 0x28, verb = 0xf09, param = 0x0 value = 0x80000000 I have attached the trace file. Polling was disabled for both tests.
Then the jack detection isn't reliable right after resume. The trace log shows: kworker/u16:66-3115 [002] .... 200.446257: hda_send_cmd: [0:0] val=28f0900 kworker/u16:66-3115 [002] .... 200.446289: hda_get_response: [0:0] val=0 so the chip returned 0 here. Maybe we just need to put some delay after resume power up. Could you try the test patch below?
Created attachment 177951 [details] Test patch
If the patch above helps, try to reduce the value 100 to 10, too.
That patch seems to have solved the issue, thanks! I'll let you know again after testing it for a couple more days, and reducing the sleep time to 10.
My results after further testing: -Reducing sleep time to 10ms still works -Reducing to 5ms doesn't work I have another PC at home with a Gigabyte GA-78LMT-USB3 rev 5.0 motherboard, which has VIA VT2021 sound: http://www.gigabyte.com/products/product-page.aspx?pid=4602#sp The PC is running Windows so I booted it up in a Ubuntu live USB, and can confirm that the same issue is present. I didn't test the kernel patch on it, however. The following bug report, also for a Gigabyte motherboard with VIA VT2020 sound, might also be caused by the same issue: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1365769
OK, below is the patch for 4.1 kernel to be upstreamed. Unfortunately it's not directly applicable to older kernels. You'd need to replace regcache_sync() call with two calls snd_hda_codec_resume_amp(codec); snd_hda_codec_resume_cache(codec); I'm going to submit it and queue for the next pull request.
Created attachment 178401 [details] Fix patch for 4.1 upstream kernel
The patch was queued. Feel free to reopen if it still doesn't work.