HDMI hot-plug/ELD issues

HDMI hot-plug/ELD issues

[pl bossart]

Hi,
I was testing my pulseaudio AC3 passthrough patch on my new laptop
(all Intel hw, Corei5/IbexPeak, 2.6.35) and noticed a set of issues
with the HDMI output:
1. Playback can happen even if there's no HDMI cable plugged. Or when
I remove the cable, the player isn't notified and keeps sending data
to the driver. This is fine for PCM but I noticed that the receiver
can handle some trouble synchronizing with in AC3-passthrough mode if
the cable is inserted after the playback starts. It would be much
cleaner to allow playback only when there's an actual cable connected,
and to return -ENODEV or something to apps when this happens.
2. It looks like the ELD info is invalid in /proc/asound/cards/. Tried
both with my TV and AV receiver, no luck, all zeroes except for
'monitor_present'

monitor_present         1
eld_valid               0
monitor_name
connection_type         HDMI
eld_version             [0x0] reserved
edid_version            [0x0] no CEA EDID Timing Extension block present
manufacture_id          0x0
product_id              0x0
port_id                 0x0
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC
FLW/FRW FLH/FRH TC FCH
sad_count               0

Is there a missing link with the display driver so that this info
would make sense? I remember having a conversation with Fengguang Wu
on this, but I can't remember what the outcome was. Or is this a case
of back luck with broken hardware not sending the legal EDID info?
Thanks for your help on this.
-Pierre

Re: HDMI hot-plug/ELD issues

[Wu Fengguang]

Hi Pierre,

On Thu, Aug 19, 2010 at 05:25:53PM -0500, pl bossart wrote:
> Hi,
> I was testing my pulseaudio AC3 passthrough patch on my new laptop
> (all Intel hw, Corei5/IbexPeak, 2.6.35) and noticed a set of issues
> with the HDMI output:
> 1. Playback can happen even if there's no HDMI cable plugged. Or when
> I remove the cable, the player isn't notified and keeps sending data
> to the driver. This is fine for PCM but I noticed that the receiver
> can handle some trouble synchronizing with in AC3-passthrough mode if
> the cable is inserted after the playback starts. It would be much
> cleaner to allow playback only when there's an actual cable connected,
> and to return -ENODEV or something to apps when this happens.

We used to turn off HDMI link when not playing. However that caused
loss of 0.5s samples when starting next playback, due to the slow
responding HDMI sink devices (in fact all my tested monitors/AV
receivers have this problem).

What's your test case? Keep playing during plug/unplug, or
play -- plug -- stop playing -- unplug -- play a new track?

Then there's the question whether to send -ENODEV to the audio player,
or to send udev events (for pulseaudio) on hotplug events, or to
disable HDMI link only for passthrough mode, or whatever policy.
Any ideas?

> 2. It looks like the ELD info is invalid in /proc/asound/cards/. Tried
> both with my TV and AV receiver, no luck, all zeroes except for
> 'monitor_present'
> 
> monitor_present         1
> eld_valid               0
> monitor_name
> connection_type         HDMI
> eld_version             [0x0] reserved
> edid_version            [0x0] no CEA EDID Timing Extension block present
> manufacture_id          0x0
> product_id              0x0
> port_id                 0x0
> support_hdcp            0
> support_ai              0
> audio_sync_delay        0
> speakers                [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC
> FLW/FRW FLH/FRH TC FCH
> sad_count               0
> 
> Is there a missing link with the display driver so that this info
> would make sense? I remember having a conversation with Fengguang Wu
> on this, but I can't remember what the outcome was. Or is this a case
> of back luck with broken hardware not sending the legal EDID info?
> Thanks for your help on this.

Sorry we have not implemented the ELD feature in video driver.  The
Intel gfx driver should read&parse HW EDID and pass the ELD info to
the audio driver.

Thanks,
Fengguang

Re: HDMI hot-plug/ELD issues

[pl bossart]

>> 1. Playback can happen even if there's no HDMI cable plugged. Or when
>> I remove the cable, the player isn't notified and keeps sending data
>> to the driver. This is fine for PCM but I noticed that the receiver
>> can handle some trouble synchronizing with in AC3-passthrough mode if
>> the cable is inserted after the playback starts. It would be much
>> cleaner to allow playback only when there's an actual cable connected,
>> and to return -ENODEV or something to apps when this happens.
>
> We used to turn off HDMI link when not playing. However that caused
> loss of 0.5s samples when starting next playback, due to the slow
> responding HDMI sink devices (in fact all my tested monitors/AV
> receivers have this problem).

I think it's fine if you leave the link on.

> What's your test case? Keep playing during plug/unplug, or
> play -- plug -- stop playing -- unplug -- play a new track?

The player keeps playing, and then I unplug/replug/unplug/replug the
cable. At some point the receiver will lose the sync with compressed
data.

> Then there's the question whether to send -ENODEV to the audio player,
> or to send udev events (for pulseaudio) on hotplug events, or to
> disable HDMI link only for passthrough mode, or whatever policy.
> Any ideas?

I think we really need a consistent approach for all HDMI devices so
that middleware, PulseAudio specifically works without quirks and
hardware-specific work-arounds.
Ideally when the HDMI cable is plugged you would register a new card
and this would generate the relevant hot-plug events.However in the
case of HDAudio you have 2 devices for the same card. I am not sure
ALSA would generate hot-plug events if you registered/exposed the
HDMI-related devices only when a cable is played. Alternatively we
could leave the devices exposed at all times generate a dedicated HDMI
event, and have PulseAudio handle it.
How is this handled on non-Intel hardware?

>> Is there a missing link with the display driver so that this info
>> would make sense? I remember having a conversation with Fengguang Wu
>> on this, but I can't remember what the outcome was. Or is this a case
>> of back luck with broken hardware not sending the legal EDID info?
>> Thanks for your help on this.
>
> Sorry we have not implemented the ELD feature in video driver.  The
> Intel gfx driver should read&parse HW EDID and pass the ELD info to
> the audio driver.

It doesn't seem like rocket science, is this something that could be
patched? That really needs to be fixed, so that we can work with
Takashi and expose the ELD info to user-space. All this information is
badly needed by middleware.
-Pierre