Bug 70511

Please give alsa-info.sh output at the HDMI plugged.  Run it with --no-upload option and attach the output to Bugzilla (don't paste).

Then check /proc/asound/card*/eld#* files.  They indicate which HDMI/DP audio codec has connection and ELD.  If any of them doesn't indicate the connection and the valid ELD, that's the problem.  In that case, the problem is rather in the video side.

If you see a connection there, try to play with that port.  Typically, in a raw format, you can play like "aplay -Dhdmi:0,1 foo.wav" or such.

Created attachment 125941 [details]
alsa-info output (gziped)

cat /proc/asound/card0/codec#0

...
...

cat /proc/asound/card0/eld#0.0
monitor_present		1
eld_valid		1
monitor_name		LaCie 324i
connection_type		HDMI
eld_version		[0x2] CEA-861D or below
edid_version		[0x3] CEA-861-B, C or D
manufacture_id		0x6130
product_id		0x24c2
port_id			0x0
support_hdcp		0
support_ai		0
audio_sync_delay	0
speakers		[0x4f] FL/FR LFE FC RL/RR RLC/RRC
sad_count		3
sad0_coding_type	[0x1] LPCM
sad0_channels		2
sad0_rates		[0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad0_bits		[0xe0000] 16 20 24
sad1_coding_type	[0x2] AC-3
sad1_channels		6
sad1_rates		[0xe0] 32000 44100 48000
sad1_max_bitrate	640000
sad2_coding_type	[0x7] DTS
sad2_channels		6
sad2_rates		[0x6c0] 44100 48000 88200 96000
sad2_max_bitrate	1536000

monitor name matches.

eld#0.1, and eld#0.2 shows:
monitor_present		0
eld_valid		0

which also should be right.

triggers the receiver, but no sound:
aplay -Dhdmi:0,0 /usr/share/sounds/login.wav

triggers nothing, which was expected.
aplay -Dhdmi:0,1 /usr/share/sounds/login.wav
aplay -Dhdmi:0,2 /usr/share/sounds/login.wav

oops forgot the codec: 
Codec: Intel Haswell HDMI

Judging from the information, there is nothing wrong in the audio side.  The codec detected the ELD, and set up.  Since the receiver is triggered, something is streamed out.

If it's because of the status bits, you can try to adjust ICE958 bits via iecset program.  This might help although I don't bet it.

Other than that, I have no clue.  In that case, the problem is likely in the video side.  Then you'd better reassign the bug component to Video/Intel and ping guys there.  Boot kernel with drm.debug=0x0e and get the kernel messages while you're testing, and attach it to bugzilla.

i will test with drm.debug=0x0e

Created attachment 126021 [details]
dmesg with drm debug

this is the dmesg output after a reboot with drm.debug on. efter system is booted the screen laptop screen is set off and mini-dp/hdmi is set on.
when using aplay nothing new is added to dmesg.

Mengdong, any ideas?

Hi Martin,

Could your clarify how many HDMI/DP output ports t440p has and how you connect them?

-  t440p HDMI output -> HDMI input of HiFi receiver, HDMI ouput of HiFi receiver -> HDMI input of an monitor
   Is this your connection?
   You want to get sound output from this monitor?
   Can you have video output on this monitor?


-  How does Mini-DP connect?


Also, could you attach the output of intel_audio_dump, before and when you using aplay to play audio to HDMI?


Thanks
Mengdong

Created attachment 126131 [details]
intel_audio_dump before sound was played

Created attachment 126141 [details]
intel_audio_dump after sound was played

The T440p only have 1 x VGA, 1 x Mini-DP

My setup is this:

  t440p Mini-DP
        |
  Mini-DP / HDMI converter 
        |
    HDMI cable 
        |
 Lindy HDMI to Toslink extractor box -- TosLink cable -- Pioneer receiver
        | 
    HDMI cable 
        |
   LaCie monitor

I have perfect video on the monitor and I dont want/need sound on the monitor.

Hm, did you test whether the sound can come from TV via HDMI from this machine at all, instead of splitting to a receiver?  Maybe it's better to check from that -- whether the HDMI audio works at all.

Also, did this same setup work with another machine?

Another thing to test is playing with different formats (S16 instead of S32) or different sample rates.  I don't expect much that this would influence on the behavior, but who knows...

I have not tested with a TV. Dont have one within range.
The current setup works with my previous laptop, and my desktop PC which have a Radeon card with 2 x Mini-DP ports.

I'll test the different formats...

Hi Jani,

I feel the the DDI mode for pipe B in the audio dump is abnormal. Could you help to clarify why gfx driver configure its mode to "HDMI mode", not "DP SST mode"?

Pipe B DDI Function Control
PIPE DDI Function Enable				[0x1]
PIPE DDI selection					[0x1] Digital Port B
PIPE DDI Mode 						[0x0] HDMI mode
BITS per color						[0x0]

Martin's machine use pipe B for port B (mini-DP). 
Although he uses Mini-DP / HDMI converter on port B, I think for Haswell display HW or gfx driver, the pipe should still be configured in DP mode. Is my understanding right?

The audio enabling code in i915 driver depends on the mode to program N value for DP or HDMI output.

Thanks
Mengdong

I just realized the port B supports DP++ which can change to HDMI mode when it detects the DP/HDMI convertor.

We'll test if HDMI audio can work using DP port -> DP/HDMI convertor -> HDMI audio capable monitor. We've not tested this case before.

Besides the PIPE DDI mode, all other audio dump info seems okay.

Thanks
Mengdong

I have a TV on which audio and video used to work from a machine with a radeon card(OSS driver).

However, on my t440p, audio does not work using a mini DP->HDMI converter(with audio support). Also, eld_valid 0. Is this related to this bug, or should I submit a new one?

cat /proc/asound/card0/eld#0.0
monitor_present		1
eld_valid		0

FYI, it doesnt work on 3.14-rc5 either.

... not in 3.14 either.

A little progress has been made with 3.14.4 kernel.

I tried booting my laptop with the lid closed, and for some reason the eDP1 output (laptop screen) was not detected, only the HDMI1,2 DP1,2 VIRTUAL1 and VGA1 was found. Now the sound gets sent to my AV receiver.

Rebooting the laptop with laptop lid open, and eDP1 visible in xrandr, the sound doesnt work again.

just swiched to debian jessie/testing. no luck with vanilla installation. same story.

Could you check i915.disable_power_well=1 option?

My current setup seems to have the following default:

cat /sys/module/i915/parameters/disable_power_well
1

... without me forcing it. Do you mean switch it off ( 0 )?

Oh, yes, my typo, please pass 0.  It's meant disabling to disable :)
(i.e. always enabling power well.)

That did the trick. Setting disable_power_well = 0 reliably enables the sound each time I try. :-)

OK, then it's likely the dup of bug 74861.

Perhaps, although I haven't ever experienced fast playing audio on either HDMI or the speakers...

The end result can be different depending on the device.  The cause seems that the audio (or some part of graphics) device isn't fully initialized due to power well switching on/off.

Many devices still accept the streaming in the uninitialized state but then the sample rate or sample bits can be different from the actual stream, and you'll hear the fast playing audio in such a case.

Assuming dupe, please reopen if the problem persists with kernels that have the fix for bug 74861. Thanks for the report.

*** This bug has been marked as a duplicate of bug 74861 ***