HDMI audio hot-plug detection does not work well with laptop running on battery with 14.04

Bug #1383997 reported by Po-Hsu Lin
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HWE Next
Triaged
High
David Henningsson
linux (Ubuntu)
Incomplete
High
David Henningsson

Bug Description

CID: 201307-14037 Dell Vostro 5470

There is no HDMI audio output option available when you connect the HDMI monitor (with speaker) to this system.

Verified with cold plug, still no luck.

However, HDMI audio could be detected with cold plug on 12.04.4 (3.11 kernel) stock Ubuntu, tested with LiveUSB

Alsa-info:
http://www.alsa-project.org/db/?f=8e5ccdaae7aa4b3a05862385b902f824be65f0bd

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-37-generic 3.13.0-37.64
ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
Uname: Linux 3.13.0-37-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 1589 F.... pulseaudio
 /dev/snd/controlC1: ubuntu 1589 F.... pulseaudio
CRDA:
 country TW:
  (2402 - 2472 @ 40), (3, 27)
  (5270 - 5330 @ 40), (3, 17), DFS
  (5735 - 5815 @ 40), (3, 30)
CurrentDesktop: Unity
Date: Tue Oct 21 22:44:45 2014
HibernationDevice: RESUME=UUID=420e55c0-b179-44d6-93d7-82393cdeec68
InstallationDate: Installed on 2014-10-21 (0 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: Dell Inc. Vostro 5470
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-37-generic.efi.signed root=UUID=a975e1af-1e52-4f17-8e69-190b4dc36b48 ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-37-generic N/A
 linux-backports-modules-3.13.0-37-generic N/A
 linux-firmware 1.127.7
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/23/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A01
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: White Tip Mountain
dmi.board.vendor: Intel Corp.
dmi.board.version: FAB3
dmi.chassis.asset.tag: Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: Intel Corporation
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnDellInc.:bvrA01:bd08/23/2013:svnDellInc.:pnVostro5470:pvr:rvnIntelCorp.:rnWhiteTipMountain:rvrFAB3:cvnIntelCorporation:ct9:cvr0.1:
dmi.product.name: Vostro 5470
dmi.sys.vendor: Dell Inc.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Po-Hsu Lin (cypressyew) wrote : Re: [Dell Vostro 5470] No HDMI audio with 14.04

I would say it's quite unstable, and I was informed that this could be a kernel race issue.

After I installed the 3.12 kernel on this system and cold boot into 3.13.0-37 (I forgot to switch to 3.12 on boot) with HDMI cable connected HDMI audio is now available.

But if you disconnect it, sometimes it won't disappear automatically from Sound settings.
If it's gone, hot-plug can't make the HDMI audio output available again.

Error messages could be found in dmesg:
[ 44.038792] HDMI: Unknown ELD version 10

ubuntu@201307-14037:~$ lspci -nnk | grep -i Audio -A2
00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09)
 Subsystem: Dell Device [1028:0615]
 Kernel driver in use: snd_hda_intel
--
00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04)
 Subsystem: Dell Device [1028:0615]
 Kernel driver in use: snd_hda_intel

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Further debugging information:
After the HDMI cable was disconnected, if the HDMI audio output option is still there, you could try to use "Test Sound" on it, it will disappear right away.

And if it's not detected with hot plug, the following command could make it available:
(although nothing could be heard at all)
aplay -D plug:hdmi tmp.wav

Note that only "aplay -D plughw:0,7 tmp.wav" could make a sound (with audio output manually set to HDMI)
Neither "aplay -D plughw:0,3 tmp.wav" nor "aplay -D plughw:0,8 tmp.wav" could work.

ubuntu@201307-14037:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC290 Analog [ALC290 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

penalvch (penalvch)
tags: added: bios-outdated-a09 regression-release
Changed in linux (Ubuntu):
assignee: Anthony Wong (anthonywong) → David Henningsson (diwic)
Changed in hwe-next:
status: New → Triaged
assignee: nobody → David Henningsson (diwic)
Revision history for this message
David Henningsson (diwic) wrote :

Ok, so to start from the bottom:

The aplay or speaker-test device you'd like to test with is likely "hdmi:HDMI,1", i e

aplay -D hdmi:HDMI,1 tmp.wav

Second, I wonder if this is something we've brought upon us during the upgrades and trying to get all the power savings right.

Can you try editing /etc/modprobe.d/alsa-base.conf and add:

option snd-hda-intel jackpoll_ms=500

...and reboot. Does this make detection work reliably?

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Hello David,
With "aplay -D hdmi:HDMI,1 tmp.wav" command, I can play a wav file through the speaker of a HDMI monitor
But adding:
"options snd-hda-intel jackpoll_ms=500"
Can't make the detection work properly.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

BTW, with the command:
aplay -D hdmi:HDMI,1 Media-Convert_test3_PCM_Stereo_VBR_16SS_11025Hz.wav

The rate will be incorrect,
Playing WAVE 'Media-Convert_test3_PCM_Stereo_VBR_16SS_11025Hz.wav' : Signed 16 bit Little Endian, Rate 11025 Hz, Stereo
Warning: rate is not accurate (requested = 11025Hz, got = 32000Hz)
         please, try the plug plugin

And after adding the new entry to /etc/modprobe.d/alsa-base.conf,
the HDMI output option in "Sound Settings" won't be available even you play the wav file with the aplay command.

Revision history for this message
David Henningsson (diwic) wrote :

> Warning: rate is not accurate (requested = 11025Hz, got = 32000Hz) please, try the plug plugin

This is nothing to worry about. The hardware does not support 11025Hz, and the string "-D hdmi:HDMI,1" does not allow alsa to insert any sample rate converter.

> And after adding the new entry to /etc/modprobe.d/alsa-base.conf, the HDMI output option in "Sound Settings" won't be available
> even you play the wav file with the aplay command.

So what you're saying is that adding "jackpoll_ms = 500" actually makes things worse? That's very surprising. If the device show up when you do things with it (such as aplay) that indicates a power management problem, i e, the device does not wake up on plug/unplug. And jackpoll_ms = 500 should keep the power on all the time.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

To make it more clear,
I re-install 14.04.1 more than three times on this system in the past few days,
it seems that when it's unplugged, the HDMI audio hot-plug detection will fail.
But it work well with adapter plugged.

And adding the "jackpoll_ms = 500" entry, could make it work without adapter plugged.

Test case:
1. Boot with AC connected, hot-plug the HDMI cable to see if the detection works
2. Unplug the HDMI cable and reboot without AC connected
3. Hot-plug the HDMI cable to see if the detection works
4. Add the "jackpoll_ms = 500" entry and reboot without AC connected
5. Hot-plug the HDMI cable to see if the detection works

Actual result:
* HDMI audio detection works with step 1, but it won't be detected on step 3. After the new entry was added, detection works on step 5.

Similar issue could be found in bug 1393701
Thanks

Revision history for this message
David Henningsson (diwic) wrote :

So in comment #9 you say that "jackpoll_ms = 500" will make detection work,
and in comment #6 you say that "jackpoll_ms = 500" will not make detection work - could you clarify?

Is there a specific case where "jackpoll_ms = 500" does not help?

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

I would say let's ignore comment #6, I can't reproduce it anymore, sorry for the confusion.

I tried to install 14.04.1 + 3.13.0-37 kernel to reproduce it, but the speaker audio output changed to "Dummy Output", which is totally different from the environment in the beginning of this report.

Therefore I tested it with 14.04.1 stock image + update (3.13.0-39), and get the result in comment #9
"jackpoll_ms = 500" make the detection work without AC plugged.

Ara Pulido (ara)
Changed in linux (Ubuntu):
importance: Medium → High
Po-Hsu Lin (cypressyew)
tags: added: 201305-13624 201306-13869 201402-14675 taipei-lab
removed: blocks-hwcert taipie-lab
Revision history for this message
David Henningsson (diwic) wrote :

Hi Po-Hsu,

So Timo tested and confirmed the bug too. And also that using

options snd-hda-intel power_save_controller=N

...in /etc/modprobe.d/alsa-base.conf also fixes the issue, and is less invasive than jackpoll_ms=500. The question is if using the above power_save_controller change causes worse battery life? If it does not, maybe we could deploy it for everyone.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Hello David,

I'm not sure to what extent this tweak will affect the battery life.

I tried to measure the power consumption today, with and without these two options individually.
But I can't tell the real difference between them, the reading will jump within a certain range.
Maybe the euipement we have here (IDRC CP-268) is not up for this job (it's being tested with adapter connected), or maybe I don't have enough knowledge for using it.

Test enviroment:
Laptop with battery removed, Wifi / Bluetooth turned off, backlight tuned down to the lowest level.
Power comsumption (total wattage) measured by IDRC CP-268, with laptop adapter connected to it.

Test result:
Wattage jumps aroung 11.31 ~ 11.38 in these three secnerios.

If there is any difference, it looks like it's less than 0.1 watt, but again, I'm not very confident about this.

If you need a much more precise test report, I think I can imporve it by choosing a SSD laptop, with all extra modules removed. And sample the reading every 10 minute to get an average. (Or do you have any recommended testing technique or software?)

Also, there is a simliar bug reported by QA before:
https://bugs.launchpad.net/somerville/+bug/1067672
From here, maybe it indicates that the "options snd-hda-intel power_save_controller=N" could be an acceptable fix.

Revision history for this message
David Henningsson (diwic) wrote :

Hi Po-Hsu,

Unfortunately testing with a wattage meter on AC power will not work. The power saving is disabled when on AC power anyhow, it is only enabled when on battery power (and that's why we have the bug only when on battery power too).

Changed in hwe-next:
importance: Undecided → High
Revision history for this message
David Henningsson (diwic) wrote :

Waiting for some power measures to figure out if power_save_controller=N has any practical difference or not

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Anthony Wong (anthonywong) wrote :

Discussed in HWE sprint, Hui will do some testing on Lenovo machines from Beijing office to check if the parameter is necessary.

Po-Hsu Lin (cypressyew)
summary: - [Dell Vostro 5470] No HDMI audio with 14.04
+ HDMI audio hot-plug detection does not work well with laptop running on
+ battery with 14.04
Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Power consumption sampled with powerstat on 201208-11536 Dell Latitude 6430u

Sample rate: 15s, with 360 data points (90 min)
Result:
  A. Without the "options snd-hda-intel power_save_controller=N"
      1. with "sudo pm-powersave false"
          4.18 Watts on Average with Standard Deviation 0.27
      2. with "sudo pm-powersave true"
          4.17 Watts on Average with Standard Deviation 0.24
  B. With the "options snd-hda-intel power_save_controller=N"
      1. with "sudo pm-powersave false"
            4.13 Watts on Average with Standard Deviation 0.20
      2. with "sudo pm-powersave true"
            4.13 Watts on Average with Standard Deviation 0.17

Hardware config:
This is a laptop with SSD, with wireless card removed, and Media Card / Mic / Camera / WWAN / WLAN / BT disabled in BIOS.

System settings:
* 14.04.1 + update
* auto update disabled
* no lock after sceen off
* idle time set to 1min
* Keyboard backlight off
* screen backlight set to minimum
* ifconfig will be disabled later

Scenario:
1. With laptop powered off, disconnect the cable after the battery is fully charged
2. Power it on around 5 seconds later after unplugging the adapter
3. Run a test script manually right after boot into desktop:
#!/bin/bash
sudo ifconfig eth0 down
sudo pm-powersave false
powerstat 15 360 | tee 1-powersave-false
4. Leave it there for 90 minutes, then modify the script (or add parameter) for next cycle, power off.

Attachment is the test report and the alsa-base.conf config file
Please double confirm this with another tester.
Thank you

Revision history for this message
David Henningsson (diwic) wrote :

Thanks for testing and sorry for the slow reply.

But did you test with a machine affected by the bug? I'm asking because you seem to have been testing an Ivy Bridge machine, and the bug is reported for an Haswell-ULT platform. So far I've only heard of Haswell and Broadwell being affected by this.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Oh my,
didn't notice this platform specific issue.
I pick this system because it's a laptop with SSD, and modules are easy to remove.
I think I will need to retest this, please ignore the test result.
Thanks

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.