Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

It looks like this issue is still here.

Having a pioneer receiver (vsx-928), audio only works when using
interlaced modes OR 1080p@24, 720 etc all work fine... everything
higher just does not produce sound.

Plugging directly into the TV produced sound just fine..

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Daniel Vetter]

On Wed, Oct 09, 2013 at 11:09:38AM +0200, Jasper Smet wrote:
> It looks like this issue is still here.
> 
> Having a pioneer receiver (vsx-928), audio only works when using
> interlaced modes OR 1080p@24, 720 etc all work fine... everything
> higher just does not produce sound.
> 
> Plugging directly into the TV produced sound just fine..

We need a notch more information about your hw, my telephatic abilities
are unfortunately not that good ...

dmesg with drm.debug=0xe added to your cmdline with the receiver
connected would be a good start.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

Sorry,

Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
my Pioneer VSX-928 which is then connected to my Panasonic tv

Running latest stable Openelec build (3.2.2). (tried different builds
using stable/unstable drivers)

Here are some logs i pulled while i was debugging the issue with one
of the OpenElec developers.

xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
alsa playback devices: http://sprunge.us/KZKX
xrandr modes: http://sprunge.us/DhFK
dmesg: http://sprunge.us/XRGP

Hope this helps?

On Wed, Oct 9, 2013 at 12:34 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Oct 09, 2013 at 11:09:38AM +0200, Jasper Smet wrote:
>> It looks like this issue is still here.
>>
>> Having a pioneer receiver (vsx-928), audio only works when using
>> interlaced modes OR 1080p@24, 720 etc all work fine... everything
>> higher just does not produce sound.
>>
>> Plugging directly into the TV produced sound just fine..
>
> We need a notch more information about your hw, my telephatic abilities
> are unfortunately not that good ...
>
> dmesg with drm.debug=0xe added to your cmdline with the receiver
> connected would be a good start.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Daniel Vetter]

On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
> Sorry,
> 
> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
> my Pioneer VSX-928 which is then connected to my Panasonic tv
> 
> Running latest stable Openelec build (3.2.2). (tried different builds
> using stable/unstable drivers)

That's really old ... Can you please test on something more modern? We
made tons of fixes to the hdmi infoframe code.
> 
> Here are some logs i pulled while i was debugging the issue with one
> of the OpenElec developers.
> 
> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
> alsa playback devices: http://sprunge.us/KZKX
> xrandr modes: http://sprunge.us/DhFK
> dmesg: http://sprunge.us/XRGP

When you have a new kernel please boot with drm.debug=0xe added to your
kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
noise isn't in there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

Ok will pass the info when i get home later this day.

On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>> Sorry,
>>
>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>
>> Running latest stable Openelec build (3.2.2). (tried different builds
>> using stable/unstable drivers)
>
> That's really old ... Can you please test on something more modern? We
> made tons of fixes to the hdmi infoframe code.
>>
>> Here are some logs i pulled while i was debugging the issue with one
>> of the OpenElec developers.
>>
>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>> alsa playback devices: http://sprunge.us/KZKX
>> xrandr modes: http://sprunge.us/DhFK
>> dmesg: http://sprunge.us/XRGP
>
> When you have a new kernel please boot with drm.debug=0xe added to your
> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
> noise isn't in there.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

As promissed i added the params to the kernel boot and here's the
dmesg output with debugging enabled:

http://sprunge.us/iEQR

Hope this helps!

On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
> Ok will pass the info when i get home later this day.
>
> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>> Sorry,
>>>
>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>
>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>> using stable/unstable drivers)
>>
>> That's really old ... Can you please test on something more modern? We
>> made tons of fixes to the hdmi infoframe code.
>>>
>>> Here are some logs i pulled while i was debugging the issue with one
>>> of the OpenElec developers.
>>>
>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>> alsa playback devices: http://sprunge.us/KZKX
>>> xrandr modes: http://sprunge.us/DhFK
>>> dmesg: http://sprunge.us/XRGP
>>
>> When you have a new kernel please boot with drm.debug=0xe added to your
>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>> noise isn't in there.
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jani Nikula]

On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
> As promissed i added the params to the kernel boot and here's the
> dmesg output with debugging enabled:
>
> http://sprunge.us/iEQR

Similar dmesg for when you connect directly to the tv (and audio works)
might prove useful.

Is your expectation that the VSX-928 picks up the sound, or pass through
to the tv? Is it possible to try both (I honestly don't know)?

It might prove useful to file a bug on DRM/Intel at [1] to track
this. Then it won't get lost even if this thread quiets down.


Thanks,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI


>
> Hope this helps!
>
> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>> Ok will pass the info when i get home later this day.
>>
>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>> Sorry,
>>>>
>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>
>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>> using stable/unstable drivers)
>>>
>>> That's really old ... Can you please test on something more modern? We
>>> made tons of fixes to the hdmi infoframe code.
>>>>
>>>> Here are some logs i pulled while i was debugging the issue with one
>>>> of the OpenElec developers.
>>>>
>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>> alsa playback devices: http://sprunge.us/KZKX
>>>> xrandr modes: http://sprunge.us/DhFK
>>>> dmesg: http://sprunge.us/XRGP
>>>
>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>> noise isn't in there.
>>> -Daniel
>>> --
>>> Daniel Vetter
>>> Software Engineer, Intel Corporation
>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>
>>
>>
>> --
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>
>
>
> -- 
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

I managed do this quickly before i got off to work:

Dmesg output with directly connected to the tv: http://sprunge.us/EhJD

Neither the VSX-928 nor the TV (passtrough) pick up sound when
connected to the AV receiver.

I noticed that when i set the resolution to 1080i@30 sound works on
the receiver but not on the TV, everything lower works fine in both
passtrough and with the receiver powered on.

Only when using 1080p24 or lower everything then works fine on both devices..

Hope this helps.

On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>> As promissed i added the params to the kernel boot and here's the
>> dmesg output with debugging enabled:
>>
>> http://sprunge.us/iEQR
>
> Similar dmesg for when you connect directly to the tv (and audio works)
> might prove useful.
>
> Is your expectation that the VSX-928 picks up the sound, or pass through
> to the tv? Is it possible to try both (I honestly don't know)?
>
> It might prove useful to file a bug on DRM/Intel at [1] to track
> this. Then it won't get lost even if this thread quiets down.
>
>
> Thanks,
> Jani.
>
>
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>
>
>>
>> Hope this helps!
>>
>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>> Ok will pass the info when i get home later this day.
>>>
>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>> Sorry,
>>>>>
>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>
>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>> using stable/unstable drivers)
>>>>
>>>> That's really old ... Can you please test on something more modern? We
>>>> made tons of fixes to the hdmi infoframe code.
>>>>>
>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>> of the OpenElec developers.
>>>>>
>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>> dmesg: http://sprunge.us/XRGP
>>>>
>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>> noise isn't in there.
>>>> -Daniel
>>>> --
>>>> Daniel Vetter
>>>> Software Engineer, Intel Corporation
>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>
>>>
>>>
>>> --
>>> Met Vriendelijke Groeten
>>>
>>> Jasper Smet
>>> Developer
>>>
>>> Twitter: josbeir
>>> E-mail: josbeir@gmail.com
>>> Mobile: 0486/41.75.45
>>
>>
>>
>> --
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jani Nikula]

On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
> I managed do this quickly before i got off to work:
>
> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>
> Neither the VSX-928 nor the TV (passtrough) pick up sound when
> connected to the AV receiver.
>
> I noticed that when i set the resolution to 1080i@30 sound works on
> the receiver but not on the TV, everything lower works fine in both
> passtrough and with the receiver powered on.
>
> Only when using 1080p24 or lower everything then works fine on both
> devices..

At a glance, the main difference seems to be:

 [drm:drm_detect_monitor_audio], Monitor has basic audio support
-[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
+[drm:drm_edid_to_eld], ELD monitor VSX-923
 [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
-[drm:drm_edid_to_eld], ELD size 9, SAD count 1
+[drm:drm_edid_to_eld], ELD size 13, SAD count 8

This is getting pretty much to unknown territory for me, so if anyone
knows anything better, please chime in!

I think I'd try using the TV's EDID with the VSX-923 to see if the
ELD/SAD difference makes, uh, a difference. Something like this:

1. connect directly to TV
2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
   sensible name, e.g. panasonic-edid. the exact source path may vary
   depending on HDMI port etc.
3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
   tell DRM to load the edid from /lib/firmware. again, the connector
   name HDMI-A-1 may very depending on HDMI port you use, do check.
5. connect to VSX-923; this should now use the EDID (and consequently
   ELD/SAD) from the TV

I haven't actually tried this myself. *grin*.

Let us know what happens. Thanks.

BR,
Jani.



>
> Hope this helps.
>
> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>> As promissed i added the params to the kernel boot and here's the
>>> dmesg output with debugging enabled:
>>>
>>> http://sprunge.us/iEQR
>>
>> Similar dmesg for when you connect directly to the tv (and audio works)
>> might prove useful.
>>
>> Is your expectation that the VSX-928 picks up the sound, or pass through
>> to the tv? Is it possible to try both (I honestly don't know)?
>>
>> It might prove useful to file a bug on DRM/Intel at [1] to track
>> this. Then it won't get lost even if this thread quiets down.
>>
>>
>> Thanks,
>> Jani.
>>
>>
>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>
>>
>>>
>>> Hope this helps!
>>>
>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>> Ok will pass the info when i get home later this day.
>>>>
>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>> Sorry,
>>>>>>
>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>
>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>> using stable/unstable drivers)
>>>>>
>>>>> That's really old ... Can you please test on something more modern? We
>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>
>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>> of the OpenElec developers.
>>>>>>
>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>
>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>> noise isn't in there.
>>>>> -Daniel
>>>>> --
>>>>> Daniel Vetter
>>>>> Software Engineer, Intel Corporation
>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>
>>>>
>>>>
>>>> --
>>>> Met Vriendelijke Groeten
>>>>
>>>> Jasper Smet
>>>> Developer
>>>>
>>>> Twitter: josbeir
>>>> E-mail: josbeir@gmail.com
>>>> Mobile: 0486/41.75.45
>>>
>>>
>>>
>>> --
>>> Met Vriendelijke Groeten
>>>
>>> Jasper Smet
>>> Developer
>>>
>>> Twitter: josbeir
>>> E-mail: josbeir@gmail.com
>>> Mobile: 0486/41.75.45
>>> _______________________________________________
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>
>
>
> -- 
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jani Nikula]

On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>> I managed do this quickly before i got off to work:
>>
>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>
>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>> connected to the AV receiver.
>>
>> I noticed that when i set the resolution to 1080i@30 sound works on
>> the receiver but not on the TV, everything lower works fine in both
>> passtrough and with the receiver powered on.
>>
>> Only when using 1080p24 or lower everything then works fine on both
>> devices..
>
> At a glance, the main difference seems to be:
>
>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>
> This is getting pretty much to unknown territory for me, so if anyone
> knows anything better, please chime in!

So my completely uneducated hunch was that the VSX-923 advertizes audio
capabilities for better quality than the TV, and together the video and
audio oversubscribe the link, unless you degrade video quality. And my
idea below is to use whatever the TV uses. I don't know if we have any
knobs to choose the audio quality somewhere, or whether the hda driver
has something for that. And then again I might be completely off here...

Jani.


>
> I think I'd try using the TV's EDID with the VSX-923 to see if the
> ELD/SAD difference makes, uh, a difference. Something like this:
>
> 1. connect directly to TV
> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>    sensible name, e.g. panasonic-edid. the exact source path may vary
>    depending on HDMI port etc.
> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>    tell DRM to load the edid from /lib/firmware. again, the connector
>    name HDMI-A-1 may very depending on HDMI port you use, do check.
> 5. connect to VSX-923; this should now use the EDID (and consequently
>    ELD/SAD) from the TV
>
> I haven't actually tried this myself. *grin*.
>
> Let us know what happens. Thanks.
>
> BR,
> Jani.
>
>
>
>>
>> Hope this helps.
>>
>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>> <jani.nikula@linux.intel.com> wrote:
>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>> As promissed i added the params to the kernel boot and here's the
>>>> dmesg output with debugging enabled:
>>>>
>>>> http://sprunge.us/iEQR
>>>
>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>> might prove useful.
>>>
>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>
>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>> this. Then it won't get lost even if this thread quiets down.
>>>
>>>
>>> Thanks,
>>> Jani.
>>>
>>>
>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>
>>>
>>>>
>>>> Hope this helps!
>>>>
>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>> Ok will pass the info when i get home later this day.
>>>>>
>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>> Sorry,
>>>>>>>
>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>
>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>> using stable/unstable drivers)
>>>>>>
>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>
>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>> of the OpenElec developers.
>>>>>>>
>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>
>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>> noise isn't in there.
>>>>>> -Daniel
>>>>>> --
>>>>>> Daniel Vetter
>>>>>> Software Engineer, Intel Corporation
>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Met Vriendelijke Groeten
>>>>>
>>>>> Jasper Smet
>>>>> Developer
>>>>>
>>>>> Twitter: josbeir
>>>>> E-mail: josbeir@gmail.com
>>>>> Mobile: 0486/41.75.45
>>>>
>>>>
>>>>
>>>> --
>>>> Met Vriendelijke Groeten
>>>>
>>>> Jasper Smet
>>>> Developer
>>>>
>>>> Twitter: josbeir
>>>> E-mail: josbeir@gmail.com
>>>> Mobile: 0486/41.75.45
>>>> _______________________________________________
>>>> Intel-gfx mailing list
>>>> Intel-gfx@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>>
>>
>>
>> -- 
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
set up a build env later this day and hope for the best :-)

On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>> I managed do this quickly before i got off to work:
>>>
>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>
>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>> connected to the AV receiver.
>>>
>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>> the receiver but not on the TV, everything lower works fine in both
>>> passtrough and with the receiver powered on.
>>>
>>> Only when using 1080p24 or lower everything then works fine on both
>>> devices..
>>
>> At a glance, the main difference seems to be:
>>
>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>
>> This is getting pretty much to unknown territory for me, so if anyone
>> knows anything better, please chime in!
>
> So my completely uneducated hunch was that the VSX-923 advertizes audio
> capabilities for better quality than the TV, and together the video and
> audio oversubscribe the link, unless you degrade video quality. And my
> idea below is to use whatever the TV uses. I don't know if we have any
> knobs to choose the audio quality somewhere, or whether the hda driver
> has something for that. And then again I might be completely off here...
>
> Jani.
>
>
>>
>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>> ELD/SAD difference makes, uh, a difference. Something like this:
>>
>> 1. connect directly to TV
>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>    depending on HDMI port etc.
>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>    ELD/SAD) from the TV
>>
>> I haven't actually tried this myself. *grin*.
>>
>> Let us know what happens. Thanks.
>>
>> BR,
>> Jani.
>>
>>
>>
>>>
>>> Hope this helps.
>>>
>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>> <jani.nikula@linux.intel.com> wrote:
>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>> As promissed i added the params to the kernel boot and here's the
>>>>> dmesg output with debugging enabled:
>>>>>
>>>>> http://sprunge.us/iEQR
>>>>
>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>> might prove useful.
>>>>
>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>
>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>> this. Then it won't get lost even if this thread quiets down.
>>>>
>>>>
>>>> Thanks,
>>>> Jani.
>>>>
>>>>
>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>
>>>>
>>>>>
>>>>> Hope this helps!
>>>>>
>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>> Ok will pass the info when i get home later this day.
>>>>>>
>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>> Sorry,
>>>>>>>>
>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>
>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>> using stable/unstable drivers)
>>>>>>>
>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>
>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>> of the OpenElec developers.
>>>>>>>>
>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>
>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>> noise isn't in there.
>>>>>>> -Daniel
>>>>>>> --
>>>>>>> Daniel Vetter
>>>>>>> Software Engineer, Intel Corporation
>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Met Vriendelijke Groeten
>>>>>>
>>>>>> Jasper Smet
>>>>>> Developer
>>>>>>
>>>>>> Twitter: josbeir
>>>>>> E-mail: josbeir@gmail.com
>>>>>> Mobile: 0486/41.75.45
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Met Vriendelijke Groeten
>>>>>
>>>>> Jasper Smet
>>>>> Developer
>>>>>
>>>>> Twitter: josbeir
>>>>> E-mail: josbeir@gmail.com
>>>>> Mobile: 0486/41.75.45
>>>>> _______________________________________________
>>>>> Intel-gfx mailing list
>>>>> Intel-gfx@lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>
>>>> --
>>>> Jani Nikula, Intel Open Source Technology Center
>>>
>>>
>>>
>>> --
>>> Met Vriendelijke Groeten
>>>
>>> Jasper Smet
>>> Developer
>>>
>>> Twitter: josbeir
>>> E-mail: josbeir@gmail.com
>>> Mobile: 0486/41.75.45
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jani Nikula]

On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
> Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
> kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
> set up a build env later this day and hope for the best :-)

Heh, good luck!

In the mean time, please send us the EDIDs from both the TV and the AV
receiver, in case we can think of something. It's the same binary file
mentioned in step 2.

BR,
Jani.



>
> On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>> I managed do this quickly before i got off to work:
>>>>
>>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>>
>>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>>> connected to the AV receiver.
>>>>
>>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>>> the receiver but not on the TV, everything lower works fine in both
>>>> passtrough and with the receiver powered on.
>>>>
>>>> Only when using 1080p24 or lower everything then works fine on both
>>>> devices..
>>>
>>> At a glance, the main difference seems to be:
>>>
>>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>>
>>> This is getting pretty much to unknown territory for me, so if anyone
>>> knows anything better, please chime in!
>>
>> So my completely uneducated hunch was that the VSX-923 advertizes audio
>> capabilities for better quality than the TV, and together the video and
>> audio oversubscribe the link, unless you degrade video quality. And my
>> idea below is to use whatever the TV uses. I don't know if we have any
>> knobs to choose the audio quality somewhere, or whether the hda driver
>> has something for that. And then again I might be completely off here...
>>
>> Jani.
>>
>>
>>>
>>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>>> ELD/SAD difference makes, uh, a difference. Something like this:
>>>
>>> 1. connect directly to TV
>>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>>    depending on HDMI port etc.
>>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>>    ELD/SAD) from the TV
>>>
>>> I haven't actually tried this myself. *grin*.
>>>
>>> Let us know what happens. Thanks.
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>>
>>>>
>>>> Hope this helps.
>>>>
>>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>>> <jani.nikula@linux.intel.com> wrote:
>>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>> As promissed i added the params to the kernel boot and here's the
>>>>>> dmesg output with debugging enabled:
>>>>>>
>>>>>> http://sprunge.us/iEQR
>>>>>
>>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>>> might prove useful.
>>>>>
>>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>>
>>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>>> this. Then it won't get lost even if this thread quiets down.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Jani.
>>>>>
>>>>>
>>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>>
>>>>>
>>>>>>
>>>>>> Hope this helps!
>>>>>>
>>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>> Ok will pass the info when i get home later this day.
>>>>>>>
>>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>>> Sorry,
>>>>>>>>>
>>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>>
>>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>>> using stable/unstable drivers)
>>>>>>>>
>>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>>
>>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>>> of the OpenElec developers.
>>>>>>>>>
>>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>>
>>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>>> noise isn't in there.
>>>>>>>> -Daniel
>>>>>>>> --
>>>>>>>> Daniel Vetter
>>>>>>>> Software Engineer, Intel Corporation
>>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Met Vriendelijke Groeten
>>>>>>>
>>>>>>> Jasper Smet
>>>>>>> Developer
>>>>>>>
>>>>>>> Twitter: josbeir
>>>>>>> E-mail: josbeir@gmail.com
>>>>>>> Mobile: 0486/41.75.45
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Met Vriendelijke Groeten
>>>>>>
>>>>>> Jasper Smet
>>>>>> Developer
>>>>>>
>>>>>> Twitter: josbeir
>>>>>> E-mail: josbeir@gmail.com
>>>>>> Mobile: 0486/41.75.45
>>>>>> _______________________________________________
>>>>>> Intel-gfx mailing list
>>>>>> Intel-gfx@lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>
>>>>> --
>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>
>>>>
>>>>
>>>> --
>>>> Met Vriendelijke Groeten
>>>>
>>>> Jasper Smet
>>>> Developer
>>>>
>>>> Twitter: josbeir
>>>> E-mail: josbeir@gmail.com
>>>> Mobile: 0486/41.75.45
>>>
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>
>
>
> -- 
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

That will be this evening as i'm at work now :'(

On Thu, Oct 10, 2013 at 10:38 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>> Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
>> kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
>> set up a build env later this day and hope for the best :-)
>
> Heh, good luck!
>
> In the mean time, please send us the EDIDs from both the TV and the AV
> receiver, in case we can think of something. It's the same binary file
> mentioned in step 2.
>
> BR,
> Jani.
>
>
>
>>
>> On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
>> <jani.nikula@linux.intel.com> wrote:
>>> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>> I managed do this quickly before i got off to work:
>>>>>
>>>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>>>
>>>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>>>> connected to the AV receiver.
>>>>>
>>>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>>>> the receiver but not on the TV, everything lower works fine in both
>>>>> passtrough and with the receiver powered on.
>>>>>
>>>>> Only when using 1080p24 or lower everything then works fine on both
>>>>> devices..
>>>>
>>>> At a glance, the main difference seems to be:
>>>>
>>>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>>>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>>>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>>>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>>>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>>>
>>>> This is getting pretty much to unknown territory for me, so if anyone
>>>> knows anything better, please chime in!
>>>
>>> So my completely uneducated hunch was that the VSX-923 advertizes audio
>>> capabilities for better quality than the TV, and together the video and
>>> audio oversubscribe the link, unless you degrade video quality. And my
>>> idea below is to use whatever the TV uses. I don't know if we have any
>>> knobs to choose the audio quality somewhere, or whether the hda driver
>>> has something for that. And then again I might be completely off here...
>>>
>>> Jani.
>>>
>>>
>>>>
>>>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>>>> ELD/SAD difference makes, uh, a difference. Something like this:
>>>>
>>>> 1. connect directly to TV
>>>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>>>    depending on HDMI port etc.
>>>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>>>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>>>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>>>    ELD/SAD) from the TV
>>>>
>>>> I haven't actually tried this myself. *grin*.
>>>>
>>>> Let us know what happens. Thanks.
>>>>
>>>> BR,
>>>> Jani.
>>>>
>>>>
>>>>
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>>>> <jani.nikula@linux.intel.com> wrote:
>>>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>> As promissed i added the params to the kernel boot and here's the
>>>>>>> dmesg output with debugging enabled:
>>>>>>>
>>>>>>> http://sprunge.us/iEQR
>>>>>>
>>>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>>>> might prove useful.
>>>>>>
>>>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>>>
>>>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>>>> this. Then it won't get lost even if this thread quiets down.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Jani.
>>>>>>
>>>>>>
>>>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hope this helps!
>>>>>>>
>>>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>> Ok will pass the info when i get home later this day.
>>>>>>>>
>>>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>>>> Sorry,
>>>>>>>>>>
>>>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>>>
>>>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>>>> using stable/unstable drivers)
>>>>>>>>>
>>>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>>>
>>>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>>>> of the OpenElec developers.
>>>>>>>>>>
>>>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>>>
>>>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>>>> noise isn't in there.
>>>>>>>>> -Daniel
>>>>>>>>> --
>>>>>>>>> Daniel Vetter
>>>>>>>>> Software Engineer, Intel Corporation
>>>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>
>>>>>>>> Jasper Smet
>>>>>>>> Developer
>>>>>>>>
>>>>>>>> Twitter: josbeir
>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Met Vriendelijke Groeten
>>>>>>>
>>>>>>> Jasper Smet
>>>>>>> Developer
>>>>>>>
>>>>>>> Twitter: josbeir
>>>>>>> E-mail: josbeir@gmail.com
>>>>>>> Mobile: 0486/41.75.45
>>>>>>> _______________________________________________
>>>>>>> Intel-gfx mailing list
>>>>>>> Intel-gfx@lists.freedesktop.org
>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>>
>>>>>> --
>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Met Vriendelijke Groeten
>>>>>
>>>>> Jasper Smet
>>>>> Developer
>>>>>
>>>>> Twitter: josbeir
>>>>> E-mail: josbeir@gmail.com
>>>>> Mobile: 0486/41.75.45
>>>>
>>>> --
>>>> Jani Nikula, Intel Open Source Technology Center
>>>
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>>
>>
>>
>> --
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

I managed to get a custom build but overriding the edid did not seem
to work at first glance (the override itself...) can't really say why
but the pioneer receiver was still visible in the kernel logs... So
maybe the kernel option was faulty or something?

I've managed to upload the EDID files for both devices in the meantime...

pioneer AV receiver : http://d.pr/f/uYjN
panasonic TV: http://d.pr/f/AdXp


On Thu, Oct 10, 2013 at 10:53 AM, Jasper Smet <josbeir@gmail.com> wrote:
> That will be this evening as i'm at work now :'(
>
> On Thu, Oct 10, 2013 at 10:38 AM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>> Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
>>> kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
>>> set up a build env later this day and hope for the best :-)
>>
>> Heh, good luck!
>>
>> In the mean time, please send us the EDIDs from both the TV and the AV
>> receiver, in case we can think of something. It's the same binary file
>> mentioned in step 2.
>>
>> BR,
>> Jani.
>>
>>
>>
>>>
>>> On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
>>> <jani.nikula@linux.intel.com> wrote:
>>>> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>> I managed do this quickly before i got off to work:
>>>>>>
>>>>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>>>>
>>>>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>>>>> connected to the AV receiver.
>>>>>>
>>>>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>>>>> the receiver but not on the TV, everything lower works fine in both
>>>>>> passtrough and with the receiver powered on.
>>>>>>
>>>>>> Only when using 1080p24 or lower everything then works fine on both
>>>>>> devices..
>>>>>
>>>>> At a glance, the main difference seems to be:
>>>>>
>>>>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>>>>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>>>>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>>>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>>>>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>>>>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>>>>
>>>>> This is getting pretty much to unknown territory for me, so if anyone
>>>>> knows anything better, please chime in!
>>>>
>>>> So my completely uneducated hunch was that the VSX-923 advertizes audio
>>>> capabilities for better quality than the TV, and together the video and
>>>> audio oversubscribe the link, unless you degrade video quality. And my
>>>> idea below is to use whatever the TV uses. I don't know if we have any
>>>> knobs to choose the audio quality somewhere, or whether the hda driver
>>>> has something for that. And then again I might be completely off here...
>>>>
>>>> Jani.
>>>>
>>>>
>>>>>
>>>>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>>>>> ELD/SAD difference makes, uh, a difference. Something like this:
>>>>>
>>>>> 1. connect directly to TV
>>>>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>>>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>>>>    depending on HDMI port etc.
>>>>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>>>>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>>>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>>>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>>>>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>>>>    ELD/SAD) from the TV
>>>>>
>>>>> I haven't actually tried this myself. *grin*.
>>>>>
>>>>> Let us know what happens. Thanks.
>>>>>
>>>>> BR,
>>>>> Jani.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Hope this helps.
>>>>>>
>>>>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>>>>> <jani.nikula@linux.intel.com> wrote:
>>>>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>> As promissed i added the params to the kernel boot and here's the
>>>>>>>> dmesg output with debugging enabled:
>>>>>>>>
>>>>>>>> http://sprunge.us/iEQR
>>>>>>>
>>>>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>>>>> might prove useful.
>>>>>>>
>>>>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>>>>
>>>>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>>>>> this. Then it won't get lost even if this thread quiets down.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jani.
>>>>>>>
>>>>>>>
>>>>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hope this helps!
>>>>>>>>
>>>>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>>> Ok will pass the info when i get home later this day.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>>>>> Sorry,
>>>>>>>>>>>
>>>>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>>>>
>>>>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>>>>> using stable/unstable drivers)
>>>>>>>>>>
>>>>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>>>>
>>>>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>>>>> of the OpenElec developers.
>>>>>>>>>>>
>>>>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>>>>
>>>>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>>>>> noise isn't in there.
>>>>>>>>>> -Daniel
>>>>>>>>>> --
>>>>>>>>>> Daniel Vetter
>>>>>>>>>> Software Engineer, Intel Corporation
>>>>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>>
>>>>>>>>> Jasper Smet
>>>>>>>>> Developer
>>>>>>>>>
>>>>>>>>> Twitter: josbeir
>>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>
>>>>>>>> Jasper Smet
>>>>>>>> Developer
>>>>>>>>
>>>>>>>> Twitter: josbeir
>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>> _______________________________________________
>>>>>>>> Intel-gfx mailing list
>>>>>>>> Intel-gfx@lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>>>
>>>>>>> --
>>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Met Vriendelijke Groeten
>>>>>>
>>>>>> Jasper Smet
>>>>>> Developer
>>>>>>
>>>>>> Twitter: josbeir
>>>>>> E-mail: josbeir@gmail.com
>>>>>> Mobile: 0486/41.75.45
>>>>>
>>>>> --
>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>
>>>> --
>>>> Jani Nikula, Intel Open Source Technology Center
>>>
>>>
>>>
>>> --
>>> Met Vriendelijke Groeten
>>>
>>> Jasper Smet
>>> Developer
>>>
>>> Twitter: josbeir
>>> E-mail: josbeir@gmail.com
>>> Mobile: 0486/41.75.45
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center
>
>
>
> --
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jani Nikula]

On Fri, 11 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
> I managed to get a custom build but overriding the edid did not seem
> to work at first glance (the override itself...) can't really say why
> but the pioneer receiver was still visible in the kernel logs... So
> maybe the kernel option was faulty or something?

Sorry, my bad. It's drm_kms_helper.edid_firmware=... *not*
drm.edid_firmware=... In this case, you can also change this through
sysfs:

echo -n "HDMI-A-1:panasonic-edid" > /sys/module/drm_kms_helper/parameters/edid_firmware

(again, adjust value accordingly, it's <connector-name>:<filename>
without path in <filename>, there's a bunch of dirs under /lib/firmware
it looks at)

You probably need to unplug/plug for it to take effect.

Undo by echoing "" there.

> I've managed to upload the EDID files for both devices in the meantime...

Audio data blocks as decoded by edid-decode:

> pioneer AV receiver : http://d.pr/f/uYjN

  Audio data block
    Linear PCM, max channels 1
    Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
    Supported sample sizes (bits): 24 20 16
    Linear PCM, max channels 7
    Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
    Supported sample sizes (bits): 24 20 16
    AC-3, max channels 5
    Supported sample rates (kHz): 48 44.1 32
    Maximum bit rate: 1016 kHz
    DTS, max channels 6
    Supported sample rates (kHz): 96 88.2 48 44.1
    Maximum bit rate: 1016 kHz
    One Bit Audio, max channels 5
    Supported sample rates (kHz): 44.1
    Dolby Digital+, max channels 7
    Supported sample rates (kHz): 48 44.1
    DTS-HD, max channels 7
    Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1
    MAT (MLP), max channels 7
    Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1

> panasonic TV: http://d.pr/f/AdXp

  Audio data block
    Linear PCM, max channels 1
    Supported sample rates (kHz): 48 44.1 32
    Supported sample sizes (bits): 24 20 16


So I think my theory is still plausible.


BR,
Jani.


>
>
> On Thu, Oct 10, 2013 at 10:53 AM, Jasper Smet <josbeir@gmail.com> wrote:
>> That will be this evening as i'm at work now :'(
>>
>> On Thu, Oct 10, 2013 at 10:38 AM, Jani Nikula
>> <jani.nikula@linux.intel.com> wrote:
>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>> Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
>>>> kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
>>>> set up a build env later this day and hope for the best :-)
>>>
>>> Heh, good luck!
>>>
>>> In the mean time, please send us the EDIDs from both the TV and the AV
>>> receiver, in case we can think of something. It's the same binary file
>>> mentioned in step 2.
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>>
>>>>
>>>> On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
>>>> <jani.nikula@linux.intel.com> wrote:
>>>>> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>>>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>> I managed do this quickly before i got off to work:
>>>>>>>
>>>>>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>>>>>
>>>>>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>>>>>> connected to the AV receiver.
>>>>>>>
>>>>>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>>>>>> the receiver but not on the TV, everything lower works fine in both
>>>>>>> passtrough and with the receiver powered on.
>>>>>>>
>>>>>>> Only when using 1080p24 or lower everything then works fine on both
>>>>>>> devices..
>>>>>>
>>>>>> At a glance, the main difference seems to be:
>>>>>>
>>>>>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>>>>>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>>>>>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>>>>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>>>>>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>>>>>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>>>>>
>>>>>> This is getting pretty much to unknown territory for me, so if anyone
>>>>>> knows anything better, please chime in!
>>>>>
>>>>> So my completely uneducated hunch was that the VSX-923 advertizes audio
>>>>> capabilities for better quality than the TV, and together the video and
>>>>> audio oversubscribe the link, unless you degrade video quality. And my
>>>>> idea below is to use whatever the TV uses. I don't know if we have any
>>>>> knobs to choose the audio quality somewhere, or whether the hda driver
>>>>> has something for that. And then again I might be completely off here...
>>>>>
>>>>> Jani.
>>>>>
>>>>>
>>>>>>
>>>>>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>>>>>> ELD/SAD difference makes, uh, a difference. Something like this:
>>>>>>
>>>>>> 1. connect directly to TV
>>>>>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>>>>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>>>>>    depending on HDMI port etc.
>>>>>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>>>>>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>>>>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>>>>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>>>>>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>>>>>    ELD/SAD) from the TV
>>>>>>
>>>>>> I haven't actually tried this myself. *grin*.
>>>>>>
>>>>>> Let us know what happens. Thanks.
>>>>>>
>>>>>> BR,
>>>>>> Jani.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hope this helps.
>>>>>>>
>>>>>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>>>>>> <jani.nikula@linux.intel.com> wrote:
>>>>>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>>> As promissed i added the params to the kernel boot and here's the
>>>>>>>>> dmesg output with debugging enabled:
>>>>>>>>>
>>>>>>>>> http://sprunge.us/iEQR
>>>>>>>>
>>>>>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>>>>>> might prove useful.
>>>>>>>>
>>>>>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>>>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>>>>>
>>>>>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>>>>>> this. Then it won't get lost even if this thread quiets down.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jani.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hope this helps!
>>>>>>>>>
>>>>>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>>>> Ok will pass the info when i get home later this day.
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>>>>>> Sorry,
>>>>>>>>>>>>
>>>>>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>>>>>
>>>>>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>>>>>> using stable/unstable drivers)
>>>>>>>>>>>
>>>>>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>>>>>
>>>>>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>>>>>> of the OpenElec developers.
>>>>>>>>>>>>
>>>>>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>>>>>
>>>>>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>>>>>> noise isn't in there.
>>>>>>>>>>> -Daniel
>>>>>>>>>>> --
>>>>>>>>>>> Daniel Vetter
>>>>>>>>>>> Software Engineer, Intel Corporation
>>>>>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>>>
>>>>>>>>>> Jasper Smet
>>>>>>>>>> Developer
>>>>>>>>>>
>>>>>>>>>> Twitter: josbeir
>>>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>>
>>>>>>>>> Jasper Smet
>>>>>>>>> Developer
>>>>>>>>>
>>>>>>>>> Twitter: josbeir
>>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>>> _______________________________________________
>>>>>>>>> Intel-gfx mailing list
>>>>>>>>> Intel-gfx@lists.freedesktop.org
>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Met Vriendelijke Groeten
>>>>>>>
>>>>>>> Jasper Smet
>>>>>>> Developer
>>>>>>>
>>>>>>> Twitter: josbeir
>>>>>>> E-mail: josbeir@gmail.com
>>>>>>> Mobile: 0486/41.75.45
>>>>>>
>>>>>> --
>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>
>>>>> --
>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>
>>>>
>>>>
>>>> --
>>>> Met Vriendelijke Groeten
>>>>
>>>> Jasper Smet
>>>> Developer
>>>>
>>>> Twitter: josbeir
>>>> E-mail: josbeir@gmail.com
>>>> Mobile: 0486/41.75.45
>>>
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>>
>>
>>
>> --
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>
>
>
> -- 
> Met Vriendelijke Groeten
>
> Jasper Smet
> Developer
>
> Twitter: josbeir
> E-mail: josbeir@gmail.com
> Mobile: 0486/41.75.45

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Jasper Smet]

Using drm_kms_helper.edid_firmware=HDMI-A-1:edid/pana.bin hangs the
system for +- 1 minute during boot and then goes further, it looks
like the custom edid is not loaded well. When i grep the kernel for
drm i get the following results:

[   60.678724] [drm:edid_load] *ERROR* Requesting EDID firmware
"edid/pana.bin" failed (err=-2)
[   70.018431] [drm] Got external EDID base block and 1 extension from
"edid/pana.bin" for connector "HDMI-A-1"
[   70.473422] [drm] Got external EDID base block and 1 extension from
"edid/pana.bin" for connector "HDMI-A-1"

I'm not sure if the EDID override is working or not but the end-result
is the same. No sound trouh the receiver.

And of course the one sharing the same subject as this ticket (but
does not seem to get prepended) :-)
from january 2013: =>
http://lists.freedesktop.org/archives/intel-gfx/2013-February/024875.html

Not sure if related but here i found a ticket with people describing
+- the same issue:
=> https://github.com/OpenELEC/OpenELEC.tv/issues/2683

I'm also having my doubts if its a problem with the receiver because :
=> audio with another openelec box (AMD) audio works
=> audio from my macbook using a mini displayport to hdmi cable works perfectly


On Fri, Oct 11, 2013 at 9:06 AM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Fri, 11 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>> I managed to get a custom build but overriding the edid did not seem
>> to work at first glance (the override itself...) can't really say why
>> but the pioneer receiver was still visible in the kernel logs... So
>> maybe the kernel option was faulty or something?
>
> Sorry, my bad. It's drm_kms_helper.edid_firmware=... *not*
> drm.edid_firmware=... In this case, you can also change this through
> sysfs:
>
> echo -n "HDMI-A-1:panasonic-edid" > /sys/module/drm_kms_helper/parameters/edid_firmware
>
> (again, adjust value accordingly, it's <connector-name>:<filename>
> without path in <filename>, there's a bunch of dirs under /lib/firmware
> it looks at)
>
> You probably need to unplug/plug for it to take effect.
>
> Undo by echoing "" there.
>
>> I've managed to upload the EDID files for both devices in the meantime...
>
> Audio data blocks as decoded by edid-decode:
>
>> pioneer AV receiver : http://d.pr/f/uYjN
>
>   Audio data block
>     Linear PCM, max channels 1
>     Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
>     Supported sample sizes (bits): 24 20 16
>     Linear PCM, max channels 7
>     Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
>     Supported sample sizes (bits): 24 20 16
>     AC-3, max channels 5
>     Supported sample rates (kHz): 48 44.1 32
>     Maximum bit rate: 1016 kHz
>     DTS, max channels 6
>     Supported sample rates (kHz): 96 88.2 48 44.1
>     Maximum bit rate: 1016 kHz
>     One Bit Audio, max channels 5
>     Supported sample rates (kHz): 44.1
>     Dolby Digital+, max channels 7
>     Supported sample rates (kHz): 48 44.1
>     DTS-HD, max channels 7
>     Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1
>     MAT (MLP), max channels 7
>     Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1
>
>> panasonic TV: http://d.pr/f/AdXp
>
>   Audio data block
>     Linear PCM, max channels 1
>     Supported sample rates (kHz): 48 44.1 32
>     Supported sample sizes (bits): 24 20 16
>
>
> So I think my theory is still plausible.
>
>
> BR,
> Jani.
>
>
>>
>>
>> On Thu, Oct 10, 2013 at 10:53 AM, Jasper Smet <josbeir@gmail.com> wrote:
>>> That will be this evening as i'm at work now :'(
>>>
>>> On Thu, Oct 10, 2013 at 10:38 AM, Jani Nikula
>>> <jani.nikula@linux.intel.com> wrote:
>>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>> Ok, for the distro (OpenElec) i'm using i'll need to to re-compile the
>>>>> kernel with the CONFIG_DRM_LOAD_EDID_FIRMWARE=y option so i'll try to
>>>>> set up a build env later this day and hope for the best :-)
>>>>
>>>> Heh, good luck!
>>>>
>>>> In the mean time, please send us the EDIDs from both the TV and the AV
>>>> receiver, in case we can think of something. It's the same binary file
>>>> mentioned in step 2.
>>>>
>>>> BR,
>>>> Jani.
>>>>
>>>>
>>>>
>>>>>
>>>>> On Thu, Oct 10, 2013 at 10:27 AM, Jani Nikula
>>>>> <jani.nikula@linux.intel.com> wrote:
>>>>>> On Thu, 10 Oct 2013, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>>>>>> On Thu, 10 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>> I managed do this quickly before i got off to work:
>>>>>>>>
>>>>>>>> Dmesg output with directly connected to the tv: http://sprunge.us/EhJD
>>>>>>>>
>>>>>>>> Neither the VSX-928 nor the TV (passtrough) pick up sound when
>>>>>>>> connected to the AV receiver.
>>>>>>>>
>>>>>>>> I noticed that when i set the resolution to 1080i@30 sound works on
>>>>>>>> the receiver but not on the TV, everything lower works fine in both
>>>>>>>> passtrough and with the receiver powered on.
>>>>>>>>
>>>>>>>> Only when using 1080p24 or lower everything then works fine on both
>>>>>>>> devices..
>>>>>>>
>>>>>>> At a glance, the main difference seems to be:
>>>>>>>
>>>>>>>  [drm:drm_detect_monitor_audio], Monitor has basic audio support
>>>>>>> -[drm:drm_edid_to_eld], ELD monitor Panasonic-TV
>>>>>>> +[drm:drm_edid_to_eld], ELD monitor VSX-923
>>>>>>>  [drm:parse_hdmi_vsdb], HDMI: DVI dual 0, max TMDS clock 190, latency present 0 0, video latency 0 0, audio latency 0 0
>>>>>>> -[drm:drm_edid_to_eld], ELD size 9, SAD count 1
>>>>>>> +[drm:drm_edid_to_eld], ELD size 13, SAD count 8
>>>>>>>
>>>>>>> This is getting pretty much to unknown territory for me, so if anyone
>>>>>>> knows anything better, please chime in!
>>>>>>
>>>>>> So my completely uneducated hunch was that the VSX-923 advertizes audio
>>>>>> capabilities for better quality than the TV, and together the video and
>>>>>> audio oversubscribe the link, unless you degrade video quality. And my
>>>>>> idea below is to use whatever the TV uses. I don't know if we have any
>>>>>> knobs to choose the audio quality somewhere, or whether the hda driver
>>>>>> has something for that. And then again I might be completely off here...
>>>>>>
>>>>>> Jani.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I think I'd try using the TV's EDID with the VSX-923 to see if the
>>>>>>> ELD/SAD difference makes, uh, a difference. Something like this:
>>>>>>>
>>>>>>> 1. connect directly to TV
>>>>>>> 2. copy /sys/class/drm/card0-HDMI-A-1/edid under /lib/firmware with some
>>>>>>>    sensible name, e.g. panasonic-edid. the exact source path may vary
>>>>>>>    depending on HDMI port etc.
>>>>>>> 3. make sure you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y
>>>>>>> 4. use drm.edid_firmware=HDMI-A-1:panasonic-edid module parameter to
>>>>>>>    tell DRM to load the edid from /lib/firmware. again, the connector
>>>>>>>    name HDMI-A-1 may very depending on HDMI port you use, do check.
>>>>>>> 5. connect to VSX-923; this should now use the EDID (and consequently
>>>>>>>    ELD/SAD) from the TV
>>>>>>>
>>>>>>> I haven't actually tried this myself. *grin*.
>>>>>>>
>>>>>>> Let us know what happens. Thanks.
>>>>>>>
>>>>>>> BR,
>>>>>>> Jani.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Hope this helps.
>>>>>>>>
>>>>>>>> On Thu, Oct 10, 2013 at 7:57 AM, Jani Nikula
>>>>>>>> <jani.nikula@linux.intel.com> wrote:
>>>>>>>>> On Wed, 09 Oct 2013, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>>>> As promissed i added the params to the kernel boot and here's the
>>>>>>>>>> dmesg output with debugging enabled:
>>>>>>>>>>
>>>>>>>>>> http://sprunge.us/iEQR
>>>>>>>>>
>>>>>>>>> Similar dmesg for when you connect directly to the tv (and audio works)
>>>>>>>>> might prove useful.
>>>>>>>>>
>>>>>>>>> Is your expectation that the VSX-928 picks up the sound, or pass through
>>>>>>>>> to the tv? Is it possible to try both (I honestly don't know)?
>>>>>>>>>
>>>>>>>>> It might prove useful to file a bug on DRM/Intel at [1] to track
>>>>>>>>> this. Then it won't get lost even if this thread quiets down.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jani.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hope this helps!
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 9, 2013 at 1:28 PM, Jasper Smet <josbeir@gmail.com> wrote:
>>>>>>>>>>> Ok will pass the info when i get home later this day.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 9, 2013 at 1:01 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>>>>>>>>>> On Wed, Oct 09, 2013 at 12:44:10PM +0200, Jasper Smet wrote:
>>>>>>>>>>>>> Sorry,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Intel NUC NUC Kit DC3217BY (Ivy bridge HD4000) Connected via HDMI to
>>>>>>>>>>>>> my Pioneer VSX-928 which is then connected to my Panasonic tv
>>>>>>>>>>>>>
>>>>>>>>>>>>> Running latest stable Openelec build (3.2.2). (tried different builds
>>>>>>>>>>>>> using stable/unstable drivers)
>>>>>>>>>>>>
>>>>>>>>>>>> That's really old ... Can you please test on something more modern? We
>>>>>>>>>>>> made tons of fixes to the hdmi infoframe code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here are some logs i pulled while i was debugging the issue with one
>>>>>>>>>>>>> of the OpenElec developers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> xbmc log (shows ALSA enumeration): http://sprunge.us/YJHc
>>>>>>>>>>>>> alsa playback devices: http://sprunge.us/KZKX
>>>>>>>>>>>>> xrandr modes: http://sprunge.us/DhFK
>>>>>>>>>>>>> dmesg: http://sprunge.us/XRGP
>>>>>>>>>>>>
>>>>>>>>>>>> When you have a new kernel please boot with drm.debug=0xe added to your
>>>>>>>>>>>> kernel cmdline and then grab the dmesg. Otherwise all the useful gfx debug
>>>>>>>>>>>> noise isn't in there.
>>>>>>>>>>>> -Daniel
>>>>>>>>>>>> --
>>>>>>>>>>>> Daniel Vetter
>>>>>>>>>>>> Software Engineer, Intel Corporation
>>>>>>>>>>>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>>>>
>>>>>>>>>>> Jasper Smet
>>>>>>>>>>> Developer
>>>>>>>>>>>
>>>>>>>>>>> Twitter: josbeir
>>>>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>>>
>>>>>>>>>> Jasper Smet
>>>>>>>>>> Developer
>>>>>>>>>>
>>>>>>>>>> Twitter: josbeir
>>>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Intel-gfx mailing list
>>>>>>>>>> Intel-gfx@lists.freedesktop.org
>>>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Met Vriendelijke Groeten
>>>>>>>>
>>>>>>>> Jasper Smet
>>>>>>>> Developer
>>>>>>>>
>>>>>>>> Twitter: josbeir
>>>>>>>> E-mail: josbeir@gmail.com
>>>>>>>> Mobile: 0486/41.75.45
>>>>>>>
>>>>>>> --
>>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>>
>>>>>> --
>>>>>> Jani Nikula, Intel Open Source Technology Center
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Met Vriendelijke Groeten
>>>>>
>>>>> Jasper Smet
>>>>> Developer
>>>>>
>>>>> Twitter: josbeir
>>>>> E-mail: josbeir@gmail.com
>>>>> Mobile: 0486/41.75.45
>>>>
>>>> --
>>>> Jani Nikula, Intel Open Source Technology Center
>>>
>>>
>>>
>>> --
>>> Met Vriendelijke Groeten
>>>
>>> Jasper Smet
>>> Developer
>>>
>>> Twitter: josbeir
>>> E-mail: josbeir@gmail.com
>>> Mobile: 0486/41.75.45
>>
>>
>>
>> --
>> Met Vriendelijke Groeten
>>
>> Jasper Smet
>> Developer
>>
>> Twitter: josbeir
>> E-mail: josbeir@gmail.com
>> Mobile: 0486/41.75.45
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Met Vriendelijke Groeten

Jasper Smet
Developer

Twitter: josbeir
E-mail: josbeir@gmail.com
Mobile: 0486/41.75.45

Re: intel-hda: sound via HDMI only when using interlaced modes

[David Härdeman]

I'll break etiquette here and include the entire original message below
(and top-post!) since I'm sending this to intel-gfx as well.

Since the previous mail I've tested a more recent kernel (3.8-rc6),
swapping HDMI cables and a firmware update on the receiver, none of it
helped.

I've also noticed that:

a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
the sound go away (higher frame rates) or work (1080p30). So, it has
nothing to do with interlacing.

The only difference between the output of all the intel*dump tools when
running 1080p30 and 1080p60 is included below. It's interesting to note
that all the modes that don't work have fdi_lanes = 2 while the working
ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak).

I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su
sure where the problem lies anymore...suggestions?

//David

difference between intel reg dump:

diff -Nur 1080p60/intel_reg_dumper.log 1080p30/intel_reg_dumper.log ---
1080p60/intel_reg_dumper.log	2013-02-06 21:50:35.307560443 +0100 +++
1080p30/intel_reg_dumper.log	2013-02-06 21:52:46.579566050 +0100 @@
-20,11 +20,11 @@ VSYNC_A: 0x0440043b (1084 start, 1089 end)
VSYNCSHIFT_A: 0x00000000 PIPEASRC: 0x077f0437 (1920, 1080)
-                 PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000)
-                 PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 4320000)
+                 PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000)
+                 PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000)
                  PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
                  PIPEA_DATA_N2: 0x00000000 (val 0x0 0)
-                 PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500)
+                 PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250)
                  PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000)
                  PIPEA_LINK_M2: 0x00000000 (val 0x0 0)
                  PIPEA_LINK_N2: 0x00000000 (val 0x0 0)
@@ -102,7 +102,7 @@
             PCH_SSC4_AUX_PARMS: 0x000029c5
                   PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null)))
            PCH_DPLL_ANALOG_CTL: 0x00008000
-                    PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1)
+                    PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1)
                     PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1)
                       PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7)
                       PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7)
@@ -156,10 +156,10 @@
                     TRANSACONF: 0xc0000000 (enable, active, progressive)
                     TRANSBCONF: 0x00000000 (disable, inactive, progressive)
                     TRANSCCONF: 0x00000000 (disable, inactive, progressive)
-                   FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
+                   FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
                    FDI_TXB_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
                    FDI_TXC_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
-                   FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
+                   FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
                    FDI_RXB_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
                    FDI_RXC_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
                   DPAFE_BMFUNC: 0x0001d233
@@ -208,7 +208,7 @@
                 PCH_PP_DIVISOR: 0x00186904
                       PORT_DBG: 0x00007007 (HW DRRS off)
             RC6_RESIDENCY_TIME: 0x002277e6
-           RC6p_RESIDENCY_TIME: 0x175c23e7
+           RC6p_RESIDENCY_TIME: 0x1cfed5f9
           RC6pp_RESIDENCY_TIME: 0x00000000
                GEN6_RP_CONTROL: 0x00000d91 (enabled)
                  GEN6_RPNSWREQ: 0x10000000

On Tue, Jan 29, 2013 at 11:18:26PM +0100, David Härdeman wrote:
> I've had my HTPC (Asrock Vision HT[1]) connected to my TV via a HDMI
> cable (Intel HD Graphics 4000 onboard) so far and everything has been
> working as expected.
> 
> However, I've now added a receiver (Pioneer SC LX-76[2]) between the PC
> and the TV, and now audio will only work if the PC is running in a 1080i
> mode (rather than an 1080p mode). By "work" I mean that the receiver
> will not recognize that there is a stereo PCM stream being played over
> the HDMI connection (the "LR" light won't light up, no sound, etc).
> 
> To try to minimize the variables which might affect this, I've created a
> basic test system. It boots, starts X and autologins as a newly created
> user (by nodm[4]). That user has an .xsession which simply runs "exec
> xterm". There is no /etc/X11/xorg.conf file, no pulseaudio, no .asoundrc
> file(s), etc...
> 
> Now, in a separate ssh session to the HTPC, I run "mplayer -ao
> alsa:device=hw=0.7 test.ogg" (where test.ogg is a 44.1kHz stereo file).
> 
> Using a second ssh session, I alternate between running:
> 
> DISPLAY=:0.0 xrandr --output HDMI2 --mode 1920x1080i --rate 30
> 
> and
> 
> DISPLAY=:0.0 xrandr --output HDMI2 --mode 1920x1080 --rate 60
> 
> Which reliably allows the receiver to detect the stereo stream (when the
> interlaced mode is selected) or not (when the progressive mode is
> selected).
> 
> The lspci output is included inline below[5]. I've also run the
> "intel_audio_dump", "intel_infoframes", "intel_reg_dumper" and
> "alsa-info.sh" utils when the audio is working and when it isn't.
> 
> The log files are available from my server [3].
> 
> For reference, the diff between the two "intel_reg_dumper" outputs is
> included inline[6].
> 
> The kernel is 3.7.3 (from Debian experimental), libdrm is 2.4.40, the
> xorg intel driver is 2.19.0. I've also tried earlier versions of e.g.
> the kernel without any success.
> 
> Suggestions?
> 
> -- 
> David Härdeman
> 
> [1]
> http://www.asrock.com/nettop/overview.us.asp?Model=Vision%20HT%20Series
> 
> [2]
> http://www.pioneer.eu/eur/products/42/98/405/SC-LX76-K/specs.html
> 
> [3]
> http://david.hardeman.nu/hdmilogs.tar.bz2
> 
> [4]
> http://www.enricozini.org/sw/nodm/
> 
> [5]
> lspci -vvvnnn:
> 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
>         Subsystem: ASRock Incorporation Device [1849:1898]
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Interrupt: pin A routed to IRQ 45
>         Region 0: Memory at dfe10000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: [50] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                 Address: 00000000fee0f00c  Data: 4122
>         Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>                         ExtTag- RBE- FLReset+
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                         RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>                         MaxPayload 128 bytes, MaxReadReq 128 bytes
>                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>                 LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
>                         ClockPM- Surprise- LLActRep- BwNot-
>                 LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
>         Capabilities: [100 v1] Virtual Channel
>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>                 Arb:    Fixed- WRR32- WRR64- WRR128-
>                 Ctrl:   ArbSelect=Fixed
>                 Status: InProgress-
>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>                         Status: NegoPending- InProgress-
>                 VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                         Ctrl:   Enable+ ID=1 ArbSelect=Fixed TC/VC=22
>                         Status: NegoPending- InProgress-
>         Capabilities: [130 v1] Root Complex Link
>                 Desc:   PortNumber=0f ComponentID=00 EltType=Config
>                 Link0:  Desc:   TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
>                         Addr:   00000000fed1c000
>         Kernel driver in use: snd_hda_intel
> 
> [6]
> diff -Nur 1080i/intel_reg_dumper.log 1080p/intel_reg_dumper.log
> --- 1080i/intel_reg_dumper.log	2013-01-29 22:23:20.166611170 +0100
> +++ 1080p/intel_reg_dumper.log	2013-01-29 22:25:57.906609244 +0100
> @@ -11,20 +11,20 @@
>         DISPLAY_PORT_PLL_BIOS_1: 0x00000000
>         DISPLAY_PORT_PLL_BIOS_2: 0x00000000
>                FDI_PLL_FREQ_CTL: 0x00000000
> -                     PIPEACONF: 0xc0600000 (enabled, active, if-id, rotate 0, 8bpc)
> +                     PIPEACONF: 0xc0000000 (enabled, active, pf-pd, rotate 0, 8bpc)
>                        HTOTAL_A: 0x0897077f (1920 active, 2200 total)
>                        HBLANK_A: 0x0897077f (1920 start, 2200 end)
>                         HSYNC_A: 0x080307d7 (2008 start, 2052 end)
> -                      VTOTAL_A: 0x04630437 (1080 active, 1124 total)
> -                      VBLANK_A: 0x04630437 (1080 start, 1124 end)
> -                       VSYNC_A: 0x0445043b (1084 start, 1094 end)
> -                  VSYNCSHIFT_A: 0x0000038c
> +                      VTOTAL_A: 0x04640437 (1080 active, 1125 total)
> +                      VBLANK_A: 0x04640437 (1080 start, 1125 end)
> +                       VSYNC_A: 0x0440043b (1084 start, 1089 end)
> +                  VSYNCSHIFT_A: 0x00000000
>                        PIPEASRC: 0x077f0437 (1920, 1080)
> -                 PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000)
> -                 PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000)
> +                 PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000)
> +                 PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 4320000)
>                   PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
>                   PIPEA_DATA_N2: 0x00000000 (val 0x0 0)
> -                 PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250)
> +                 PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500)
>                   PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000)
>                   PIPEA_LINK_M2: 0x00000000 (val 0x0 0)
>                   PIPEA_LINK_N2: 0x00000000 (val 0x0 0)
> @@ -78,20 +78,20 @@
>                        DSPCSURF: 0x00000000
>                     DSPCTILEOFF: 0x00000000 (0, 0)
>                       PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> -                     PFA_CTL_2: 0x00007ef2 (vscale 0.991760)
> -                     PFA_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> +                     PFA_CTL_2: 0x00007de4 (vscale 0.983521)
> +                     PFA_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
>                       PFA_CTL_4: 0x00007c40 (hscale 0.970703)
>                     PFA_WIN_POS: 0x00000000 (0, 0)
>                    PFA_WIN_SIZE: 0x00000000 (0, 0)
>                       PFB_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> -                     PFB_CTL_2: 0x00007ef2 (vscale 0.991760)
> -                     PFB_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> +                     PFB_CTL_2: 0x00007de4 (vscale 0.983521)
> +                     PFB_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
>                       PFB_CTL_4: 0x00007c40 (hscale 0.970703)
>                     PFB_WIN_POS: 0x00000000 (0, 0)
>                    PFB_WIN_SIZE: 0x00000000 (0, 0)
>                       PFC_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> -                     PFC_CTL_2: 0x00007ef2 (vscale 0.991760)
> -                     PFC_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> +                     PFC_CTL_2: 0x00007de4 (vscale 0.983521)
> +                     PFC_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
>                       PFC_CTL_4: 0x00007c40 (hscale 0.970703)
>                     PFC_WIN_POS: 0x00000000 (0, 0)
>                    PFC_WIN_SIZE: 0x00000000 (0, 0)
> @@ -102,7 +102,7 @@
>              PCH_SSC4_AUX_PARMS: 0x000029c5
>                    PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null)))
>             PCH_DPLL_ANALOG_CTL: 0x00008000
> -                    PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1)
> +                    PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1)
>                      PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1)
>                        PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7)
>                        PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7)
> @@ -111,10 +111,10 @@
>                  TRANS_HTOTAL_A: 0x0897077f (1920 active, 2200 total)
>                  TRANS_HBLANK_A: 0x0897077f (1920 start, 2200 end)
>                   TRANS_HSYNC_A: 0x080307d7 (2008 start, 2052 end)
> -                TRANS_VTOTAL_A: 0x04630437 (1080 active, 1124 total)
> -                TRANS_VBLANK_A: 0x04630437 (1080 start, 1124 end)
> -                 TRANS_VSYNC_A: 0x0445043b (1084 start, 1094 end)
> -            TRANS_VSYNCSHIFT_A: 0x0000038c
> +                TRANS_VTOTAL_A: 0x04640437 (1080 active, 1125 total)
> +                TRANS_VBLANK_A: 0x04640437 (1080 start, 1125 end)
> +                 TRANS_VSYNC_A: 0x0440043b (1084 start, 1089 end)
> +            TRANS_VSYNCSHIFT_A: 0x00000000
>                  TRANSA_DATA_M1: 0x00000000 (TU 1, val 0x0 0)
>                  TRANSA_DATA_N1: 0x00000000 (val 0x0 0)
>                  TRANSA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
> @@ -153,13 +153,13 @@
>               TRANSC_DP_LINK_N1: 0x00000000 (val 0x0 0)
>               TRANSC_DP_LINK_M2: 0x00000000 (val 0x0 0)
>               TRANSC_DP_LINK_N2: 0x00000000 (val 0x0 0)
> -                    TRANSACONF: 0xc0600000 (enable, active, interlaced)
> +                    TRANSACONF: 0xc0000000 (enable, active, progressive)
>                      TRANSBCONF: 0x00000000 (disable, inactive, progressive)
>                      TRANSCCONF: 0x00000000 (disable, inactive, progressive)
> -                   FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
> +                   FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
>                     FDI_TXB_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
>                     FDI_TXC_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
> -                   FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
> +                   FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
>                     FDI_RXB_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
>                     FDI_RXC_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
>                    DPAFE_BMFUNC: 0x0001d233
> @@ -208,7 +208,7 @@
>                  PCH_PP_DIVISOR: 0x00186904
>                        PORT_DBG: 0x00007007 (HW DRRS off)
>              RC6_RESIDENCY_TIME: 0x15742d40
> -           RC6p_RESIDENCY_TIME: 0x8bd4d0c4
> +           RC6p_RESIDENCY_TIME: 0x932ac0ec
>            RC6pp_RESIDENCY_TIME: 0x00000000
>                 GEN6_RP_CONTROL: 0x00000d91 (enabled)
>                   GEN6_RPNSWREQ: 0x0e000000
> 
> 

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Daniel Vetter]

On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote:
> I'll break etiquette here and include the entire original message below
> (and top-post!) since I'm sending this to intel-gfx as well.
> 
> Since the previous mail I've tested a more recent kernel (3.8-rc6),
> swapping HDMI cables and a firmware update on the receiver, none of it
> helped.
> 
> I've also noticed that:
> 
> a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
> the sound go away (higher frame rates) or work (1080p30). So, it has
> nothing to do with interlacing.
> 
> The only difference between the output of all the intel*dump tools when
> running 1080p30 and 1080p60 is included below. It's interesting to note
> that all the modes that don't work have fdi_lanes = 2 while the working
> ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak).
> 
> I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su
> sure where the problem lies anymore...suggestions?

I'm far away from an hdmi/snd expert, but iirc the bandwidth to squeeze
hdmi sound packets between the video frames is limited. And atm our code
does not bother with checking for that at all (and updating the
capabilities of the hdmi snd widget). But that's just an idea, I have no
idea how much bandwidth there actually is.

Paulo, do you know how this is supposed to work?
-Daniel

> 
> //David
> 
> difference between intel reg dump:
> 
> diff -Nur 1080p60/intel_reg_dumper.log 1080p30/intel_reg_dumper.log ---
> 1080p60/intel_reg_dumper.log	2013-02-06 21:50:35.307560443 +0100 +++
> 1080p30/intel_reg_dumper.log	2013-02-06 21:52:46.579566050 +0100 @@
> -20,11 +20,11 @@ VSYNC_A: 0x0440043b (1084 start, 1089 end)
> VSYNCSHIFT_A: 0x00000000 PIPEASRC: 0x077f0437 (1920, 1080)
> -                 PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000)
> -                 PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 4320000)
> +                 PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000)
> +                 PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000)
>                   PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
>                   PIPEA_DATA_N2: 0x00000000 (val 0x0 0)
> -                 PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500)
> +                 PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250)
>                   PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000)
>                   PIPEA_LINK_M2: 0x00000000 (val 0x0 0)
>                   PIPEA_LINK_N2: 0x00000000 (val 0x0 0)
> @@ -102,7 +102,7 @@
>              PCH_SSC4_AUX_PARMS: 0x000029c5
>                    PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null)))
>             PCH_DPLL_ANALOG_CTL: 0x00008000
> -                    PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1)
> +                    PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1)
>                      PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1)
>                        PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7)
>                        PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7)
> @@ -156,10 +156,10 @@
>                      TRANSACONF: 0xc0000000 (enable, active, progressive)
>                      TRANSBCONF: 0x00000000 (disable, inactive, progressive)
>                      TRANSCCONF: 0x00000000 (disable, inactive, progressive)
> -                   FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
> +                   FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
>                     FDI_TXB_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
>                     FDI_TXC_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
> -                   FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
> +                   FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
>                     FDI_RXB_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
>                     FDI_RXC_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
>                    DPAFE_BMFUNC: 0x0001d233
> @@ -208,7 +208,7 @@
>                  PCH_PP_DIVISOR: 0x00186904
>                        PORT_DBG: 0x00007007 (HW DRRS off)
>              RC6_RESIDENCY_TIME: 0x002277e6
> -           RC6p_RESIDENCY_TIME: 0x175c23e7
> +           RC6p_RESIDENCY_TIME: 0x1cfed5f9
>            RC6pp_RESIDENCY_TIME: 0x00000000
>                 GEN6_RP_CONTROL: 0x00000d91 (enabled)
>                   GEN6_RPNSWREQ: 0x10000000
> 
> On Tue, Jan 29, 2013 at 11:18:26PM +0100, David Härdeman wrote:
> > I've had my HTPC (Asrock Vision HT[1]) connected to my TV via a HDMI
> > cable (Intel HD Graphics 4000 onboard) so far and everything has been
> > working as expected.
> > 
> > However, I've now added a receiver (Pioneer SC LX-76[2]) between the PC
> > and the TV, and now audio will only work if the PC is running in a 1080i
> > mode (rather than an 1080p mode). By "work" I mean that the receiver
> > will not recognize that there is a stereo PCM stream being played over
> > the HDMI connection (the "LR" light won't light up, no sound, etc).
> > 
> > To try to minimize the variables which might affect this, I've created a
> > basic test system. It boots, starts X and autologins as a newly created
> > user (by nodm[4]). That user has an .xsession which simply runs "exec
> > xterm". There is no /etc/X11/xorg.conf file, no pulseaudio, no .asoundrc
> > file(s), etc...
> > 
> > Now, in a separate ssh session to the HTPC, I run "mplayer -ao
> > alsa:device=hw=0.7 test.ogg" (where test.ogg is a 44.1kHz stereo file).
> > 
> > Using a second ssh session, I alternate between running:
> > 
> > DISPLAY=:0.0 xrandr --output HDMI2 --mode 1920x1080i --rate 30
> > 
> > and
> > 
> > DISPLAY=:0.0 xrandr --output HDMI2 --mode 1920x1080 --rate 60
> > 
> > Which reliably allows the receiver to detect the stereo stream (when the
> > interlaced mode is selected) or not (when the progressive mode is
> > selected).
> > 
> > The lspci output is included inline below[5]. I've also run the
> > "intel_audio_dump", "intel_infoframes", "intel_reg_dumper" and
> > "alsa-info.sh" utils when the audio is working and when it isn't.
> > 
> > The log files are available from my server [3].
> > 
> > For reference, the diff between the two "intel_reg_dumper" outputs is
> > included inline[6].
> > 
> > The kernel is 3.7.3 (from Debian experimental), libdrm is 2.4.40, the
> > xorg intel driver is 2.19.0. I've also tried earlier versions of e.g.
> > the kernel without any success.
> > 
> > Suggestions?
> > 
> > -- 
> > David Härdeman
> > 
> > [1]
> > http://www.asrock.com/nettop/overview.us.asp?Model=Vision%20HT%20Series
> > 
> > [2]
> > http://www.pioneer.eu/eur/products/42/98/405/SC-LX76-K/specs.html
> > 
> > [3]
> > http://david.hardeman.nu/hdmilogs.tar.bz2
> > 
> > [4]
> > http://www.enricozini.org/sw/nodm/
> > 
> > [5]
> > lspci -vvvnnn:
> > 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
> >         Subsystem: ASRock Incorporation Device [1849:1898]
> >         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> >         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >         Latency: 0, Cache Line Size: 64 bytes
> >         Interrupt: pin A routed to IRQ 45
> >         Region 0: Memory at dfe10000 (64-bit, non-prefetchable) [size=16K]
> >         Capabilities: [50] Power Management version 2
> >                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> >                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> >         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >                 Address: 00000000fee0f00c  Data: 4122
> >         Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
> >                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
> >                         ExtTag- RBE- FLReset+
> >                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> >                         RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >                         MaxPayload 128 bytes, MaxReadReq 128 bytes
> >                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> >                 LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
> >                         ClockPM- Surprise- LLActRep- BwNot-
> >                 LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
> >                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >                 LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
> >         Capabilities: [100 v1] Virtual Channel
> >                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
> >                 Arb:    Fixed- WRR32- WRR64- WRR128-
> >                 Ctrl:   ArbSelect=Fixed
> >                 Status: InProgress-
> >                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
> >                         Status: NegoPending- InProgress-
> >                 VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> >                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> >                         Ctrl:   Enable+ ID=1 ArbSelect=Fixed TC/VC=22
> >                         Status: NegoPending- InProgress-
> >         Capabilities: [130 v1] Root Complex Link
> >                 Desc:   PortNumber=0f ComponentID=00 EltType=Config
> >                 Link0:  Desc:   TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
> >                         Addr:   00000000fed1c000
> >         Kernel driver in use: snd_hda_intel
> > 
> > [6]
> > diff -Nur 1080i/intel_reg_dumper.log 1080p/intel_reg_dumper.log
> > --- 1080i/intel_reg_dumper.log	2013-01-29 22:23:20.166611170 +0100
> > +++ 1080p/intel_reg_dumper.log	2013-01-29 22:25:57.906609244 +0100
> > @@ -11,20 +11,20 @@
> >         DISPLAY_PORT_PLL_BIOS_1: 0x00000000
> >         DISPLAY_PORT_PLL_BIOS_2: 0x00000000
> >                FDI_PLL_FREQ_CTL: 0x00000000
> > -                     PIPEACONF: 0xc0600000 (enabled, active, if-id, rotate 0, 8bpc)
> > +                     PIPEACONF: 0xc0000000 (enabled, active, pf-pd, rotate 0, 8bpc)
> >                        HTOTAL_A: 0x0897077f (1920 active, 2200 total)
> >                        HBLANK_A: 0x0897077f (1920 start, 2200 end)
> >                         HSYNC_A: 0x080307d7 (2008 start, 2052 end)
> > -                      VTOTAL_A: 0x04630437 (1080 active, 1124 total)
> > -                      VBLANK_A: 0x04630437 (1080 start, 1124 end)
> > -                       VSYNC_A: 0x0445043b (1084 start, 1094 end)
> > -                  VSYNCSHIFT_A: 0x0000038c
> > +                      VTOTAL_A: 0x04640437 (1080 active, 1125 total)
> > +                      VBLANK_A: 0x04640437 (1080 start, 1125 end)
> > +                       VSYNC_A: 0x0440043b (1084 start, 1089 end)
> > +                  VSYNCSHIFT_A: 0x00000000
> >                        PIPEASRC: 0x077f0437 (1920, 1080)
> > -                 PIPEA_DATA_M1: 0x7e1b30f0 (TU 64, val 0x1b30f0 1782000)
> > -                 PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000)
> > +                 PIPEA_DATA_M1: 0x7e3661e0 (TU 64, val 0x3661e0 3564000)
> > +                 PIPEA_DATA_N1: 0x0041eb00 (val 0x41eb00 4320000)
> >                   PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
> >                   PIPEA_DATA_N2: 0x00000000 (val 0x0 0)
> > -                 PIPEA_LINK_M1: 0x0001220a (val 0x1220a 74250)
> > +                 PIPEA_LINK_M1: 0x00024414 (val 0x24414 148500)
> >                   PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000)
> >                   PIPEA_LINK_M2: 0x00000000 (val 0x0 0)
> >                   PIPEA_LINK_N2: 0x00000000 (val 0x0 0)
> > @@ -78,20 +78,20 @@
> >                        DSPCSURF: 0x00000000
> >                     DSPCTILEOFF: 0x00000000 (0, 0)
> >                       PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> > -                     PFA_CTL_2: 0x00007ef2 (vscale 0.991760)
> > -                     PFA_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> > +                     PFA_CTL_2: 0x00007de4 (vscale 0.983521)
> > +                     PFA_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
> >                       PFA_CTL_4: 0x00007c40 (hscale 0.970703)
> >                     PFA_WIN_POS: 0x00000000 (0, 0)
> >                    PFA_WIN_SIZE: 0x00000000 (0, 0)
> >                       PFB_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> > -                     PFB_CTL_2: 0x00007ef2 (vscale 0.991760)
> > -                     PFB_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> > +                     PFB_CTL_2: 0x00007de4 (vscale 0.983521)
> > +                     PFB_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
> >                       PFB_CTL_4: 0x00007c40 (hscale 0.970703)
> >                     PFB_WIN_POS: 0x00000000 (0, 0)
> >                    PFB_WIN_SIZE: 0x00000000 (0, 0)
> >                       PFC_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1)
> > -                     PFC_CTL_2: 0x00007ef2 (vscale 0.991760)
> > -                     PFC_CTL_3: 0x00003f79 (vscale initial phase 0.495880)
> > +                     PFC_CTL_2: 0x00007de4 (vscale 0.983521)
> > +                     PFC_CTL_3: 0x00003ef2 (vscale initial phase 0.491760)
> >                       PFC_CTL_4: 0x00007c40 (hscale 0.970703)
> >                     PFC_WIN_POS: 0x00000000 (0, 0)
> >                    PFC_WIN_SIZE: 0x00000000 (0, 0)
> > @@ -102,7 +102,7 @@
> >              PCH_SSC4_AUX_PARMS: 0x000029c5
> >                    PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null)))
> >             PCH_DPLL_ANALOG_CTL: 0x00008000
> > -                    PCH_DPLL_A: 0xc4080008 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 4, FPA1 P1 4, refclk default 120Mhz, sdvo/hdmi mul 1)
> > +                    PCH_DPLL_A: 0xc4020002 (enable, sdvo high speed yes, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default 120Mhz, sdvo/hdmi mul 1)
> >                      PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1)
> >                        PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7)
> >                        PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7)
> > @@ -111,10 +111,10 @@
> >                  TRANS_HTOTAL_A: 0x0897077f (1920 active, 2200 total)
> >                  TRANS_HBLANK_A: 0x0897077f (1920 start, 2200 end)
> >                   TRANS_HSYNC_A: 0x080307d7 (2008 start, 2052 end)
> > -                TRANS_VTOTAL_A: 0x04630437 (1080 active, 1124 total)
> > -                TRANS_VBLANK_A: 0x04630437 (1080 start, 1124 end)
> > -                 TRANS_VSYNC_A: 0x0445043b (1084 start, 1094 end)
> > -            TRANS_VSYNCSHIFT_A: 0x0000038c
> > +                TRANS_VTOTAL_A: 0x04640437 (1080 active, 1125 total)
> > +                TRANS_VBLANK_A: 0x04640437 (1080 start, 1125 end)
> > +                 TRANS_VSYNC_A: 0x0440043b (1084 start, 1089 end)
> > +            TRANS_VSYNCSHIFT_A: 0x00000000
> >                  TRANSA_DATA_M1: 0x00000000 (TU 1, val 0x0 0)
> >                  TRANSA_DATA_N1: 0x00000000 (val 0x0 0)
> >                  TRANSA_DATA_M2: 0x00000000 (TU 1, val 0x0 0)
> > @@ -153,13 +153,13 @@
> >               TRANSC_DP_LINK_N1: 0x00000000 (val 0x0 0)
> >               TRANSC_DP_LINK_M2: 0x00000000 (val 0x0 0)
> >               TRANSC_DP_LINK_N2: 0x00000000 (val 0x0 0)
> > -                    TRANSACONF: 0xc0600000 (enable, active, interlaced)
> > +                    TRANSACONF: 0xc0000000 (enable, active, progressive)
> >                      TRANSBCONF: 0x00000000 (disable, inactive, progressive)
> >                      TRANSCCONF: 0x00000000 (disable, inactive, progressive)
> > -                   FDI_TXA_CTL: 0x80044b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
> > +                   FDI_TXA_CTL: 0x800c4b00 (enable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X2, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
> >                     FDI_TXB_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
> >                     FDI_TXC_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable)
> > -                   FDI_RXA_CTL: 0x8c002b50 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
> > +                   FDI_RXA_CTL: 0x8c082b50 (enable, train pattern not train, port width X2, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc enable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk)
> >                     FDI_RXB_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
> >                     FDI_RXC_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk)
> >                    DPAFE_BMFUNC: 0x0001d233
> > @@ -208,7 +208,7 @@
> >                  PCH_PP_DIVISOR: 0x00186904
> >                        PORT_DBG: 0x00007007 (HW DRRS off)
> >              RC6_RESIDENCY_TIME: 0x15742d40
> > -           RC6p_RESIDENCY_TIME: 0x8bd4d0c4
> > +           RC6p_RESIDENCY_TIME: 0x932ac0ec
> >            RC6pp_RESIDENCY_TIME: 0x00000000
> >                 GEN6_RP_CONTROL: 0x00000d91 (enabled)
> >                   GEN6_RPNSWREQ: 0x0e000000
> > 
> > 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[David Härdeman]

On Thu, Feb 07, 2013 at 11:00:13AM +0100, Daniel Vetter wrote:
>On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote:
>> I'll break etiquette here and include the entire original message below
>> (and top-post!) since I'm sending this to intel-gfx as well.
>> 
>> Since the previous mail I've tested a more recent kernel (3.8-rc6),
>> swapping HDMI cables and a firmware update on the receiver, none of it
>> helped.
>> 
>> I've also noticed that:
>> 
>> a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
>> the sound go away (higher frame rates) or work (1080p30). So, it has
>> nothing to do with interlacing.
>> 
>> The only difference between the output of all the intel*dump tools when
>> running 1080p30 and 1080p60 is included below. It's interesting to note
>> that all the modes that don't work have fdi_lanes = 2 while the working
>> ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak).
>> 
>> I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su
>> sure where the problem lies anymore...suggestions?
>
>I'm far away from an hdmi/snd expert, but iirc the bandwidth to squeeze
>hdmi sound packets between the video frames is limited. And atm our code
>does not bother with checking for that at all (and updating the
>capabilities of the hdmi snd widget). But that's just an idea, I have no
>idea how much bandwidth there actually is.

I should add that I've now installed Win7 on a separate HD. Windows has
no problems at all with audio over HDMI, no matter which resolution
and/or refresh rate, so I think cabling and other HW issues can be ruled
out. The problem is Linux-specific.

And, as I mentioned before, the TV *is* willing to accept and decode the
audio signal, so it appears that the audio stream is there....but it's
probably incompatible in some minor way...and the receiver is being
picky. That's my guess.

Anyway, how should I proceed? File a bug? In the kernel bugzilla or ALSA
bugtracker or somewhere else?

//David

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[Takashi Iwai]

At Sun, 10 Feb 2013 02:16:14 +0100,
David Härdeman wrote:
> 
> On Thu, Feb 07, 2013 at 11:00:13AM +0100, Daniel Vetter wrote:
> >On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote:
> >> I'll break etiquette here and include the entire original message below
> >> (and top-post!) since I'm sending this to intel-gfx as well.
> >> 
> >> Since the previous mail I've tested a more recent kernel (3.8-rc6),
> >> swapping HDMI cables and a firmware update on the receiver, none of it
> >> helped.
> >> 
> >> I've also noticed that:
> >> 
> >> a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
> >> the sound go away (higher frame rates) or work (1080p30). So, it has
> >> nothing to do with interlacing.
> >> 
> >> The only difference between the output of all the intel*dump tools when
> >> running 1080p30 and 1080p60 is included below. It's interesting to note
> >> that all the modes that don't work have fdi_lanes = 2 while the working
> >> ones have fdi_lanes = 1 (port width in intel_reg_dumper-speak).
> >> 
> >> I'm CC:ing the intel-gfx list as well as the ALSA list since I'm not su
> >> sure where the problem lies anymore...suggestions?
> >
> >I'm far away from an hdmi/snd expert, but iirc the bandwidth to squeeze
> >hdmi sound packets between the video frames is limited. And atm our code
> >does not bother with checking for that at all (and updating the
> >capabilities of the hdmi snd widget). But that's just an idea, I have no
> >idea how much bandwidth there actually is.
> 
> I should add that I've now installed Win7 on a separate HD. Windows has
> no problems at all with audio over HDMI, no matter which resolution
> and/or refresh rate, so I think cabling and other HW issues can be ruled
> out. The problem is Linux-specific.
> 
> And, as I mentioned before, the TV *is* willing to accept and decode the
> audio signal, so it appears that the audio stream is there....but it's
> probably incompatible in some minor way...and the receiver is being
> picky. That's my guess.
> 
> Anyway, how should I proceed? File a bug? In the kernel bugzilla or ALSA
> bugtracker or somewhere else?

FYI, ALSA bug tracker is down (and I hope it's no longer used), so put
it in either freedesktop or kernel bugzilla.


Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Alsa-user] intel-hda: sound via HDMI only when using interlaced modes

[David Härdeman]

On Thu, Feb 07, 2013 at 11:00:13AM +0100, Daniel Vetter wrote:
>On Wed, Feb 06, 2013 at 10:35:33PM +0100, David Härdeman wrote:
>> a) switching between 1080p30 and 1080p50 or 1080p60 is enough to make
>> the sound go away (higher frame rates) or work (1080p30). So, it has
>> nothing to do with interlacing.
>
>I'm far away from an hdmi/snd expert, but iirc the bandwidth to squeeze
>hdmi sound packets between the video frames is limited. And atm our code
>does not bother with checking for that at all (and updating the
>capabilities of the hdmi snd widget). But that's just an idea, I have no
>idea how much bandwidth there actually is.

I spent some time this weekend dumping the audio related registers while
outputting a stereo stream under Windows.

It turns out that 48kHz stereo audio works under windows (16bit, 48kHz
stereo audio is the default setting in Win7 for a shared audio device)
while 44.1kHz doesn't (with the Pioneer SC LX-76 receiver).

I've also tested with a different receiver (Marantz SR8002) and it
happily accepts 44.1kHz and 48kHz stereo audio (only tested with Win7)
so I'm guessing that the Pioneer receiver is being picky and/or buggy
(esp. with regard to 44.1kHz audio).

Anyway, since 48kHz audio works under Windows and not under Linux, the
Windows driver was doing something right.

I've narrowed it down to the "Pixel_Clock(HDMI)" bits (19:16) in
register AUD_CONFIG_A. The Linux driver currently sets the entire
register blindly to 0x0 (see the write to "aud_config" in
ironlake_write_eld() in drivers/gpu/drm/i915/intel_display.c) while it
should set those bits in accordance with the HDMI pixel clock of the
mode that is about to be set (which the Windows driver does).

Manually setting those bits to eg 0x9 (which would be the correct value
for a 1080p60 mode which uses a 148.5Mhz pixel clock) gets me working
48kHz audio (i.e. feature parity with Windows) when running in 1080p60.

(And on a big sidenote...the value 0x6, which corresponds to a
74.25/1.001 Mhz pixel clock, gets me working 44.1kHz *and* 48kHz audio
no matter what the resolution/refresh rate is...must be some kind of
Pioneer quirk...but I'm happy it exists).

I could write a patch, but the Intel docs (IHD-OS-V3 Pt 4, section
4.2.1, pp 87 - 88) are a bit terse so I'm a bit nervous about whether
I'd get it right or not...

-- 
David Härdeman