[RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[Anssi Hannula]

Hi all!

Currently we allow the use of CA values up to 0x31 as defined in
CEA-861-E/F. However, only CA values up to 0x19 are defined in
CEA-861-B/C/D.

HDMI specification 1.4b specifies that the CA field is to be filled
according to CEA-861-D, and DisplayPort 1.1a according to CEA-861-C.

The ELD (EDID-Like Data) format as specified by Intel HDA specification
1.0a has a speaker allocation bitmask that only accommodates speakers
present in CEA-861-D; all of the 0x20+ CAs contain speakers that do not
have a corresponding bit in ELD.

Using a CA value unsupported by sink will cause either a completely
silent output or stereo output, so I think we should try to prevent
selecting such channel maps, if feasible.

However, before doing anything, I wonder if they are actually supported
by some newer receivers (mine is 4 years old). It'd be good if someone
with a newish receiver could try the below :)
To test this, one can run (replacing XX and YY with appropriate values
from "aplay -L") on *sound git master*:
speaker-test -c6 -Dhdmi:CARD=XX,DEV=YY -m FL,FR,RL,RR,FLH,FRH
If you get some output for the RL/RR speakers, that should mean that
0x20+ CAs are supported. If there is no output except on FL/FR and there
is proper output without the "-m FL,FR,RL,RR,FLH,FRH", this means that
0x20+ CAs are not supported.

I think there are about these options for us to take:
a) drop 0x20+ CAs from channel_allocations altogether
b) put the 0x20+ CAs under a module parameter
c) only allow 0x20+ CAs if any CEA-861-E+ only speakers are specified
   in EDID. However, as ELD doesn't have bits for these, we'd have to
   employ some non-standard bits in ELD or communicate directly with
   video driver.
d) do nothing, allow the 0x20+ CAs.

IMHO we should do something, since players using ALSA channel mapping
could just automatically select a manual channel map that uses an
unsupported 0x20+ CA if the source audio stream contains such channels...

WDYT?

-- 
Anssi Hannula

Re: [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[Anssi Hannula]

01.11.2013 23:43, Anssi Hannula kirjoitti:
> Hi all!
> 
> Currently we allow the use of CA values up to 0x31 as defined in
> CEA-861-E/F. However, only CA values up to 0x19 are defined in
> CEA-861-B/C/D.
> 
> HDMI specification 1.4b specifies that the CA field is to be filled
> according to CEA-861-D, and DisplayPort 1.1a according to CEA-861-C.
> 
> The ELD (EDID-Like Data) format as specified by Intel HDA specification
> 1.0a has a speaker allocation bitmask that only accommodates speakers
> present in CEA-861-D; all of the 0x20+ CAs contain speakers that do not
> have a corresponding bit in ELD.
> 
> Using a CA value unsupported by sink will cause either a completely
> silent output or stereo output, so I think we should try to prevent
> selecting such channel maps, if feasible.
> 
> However, before doing anything, I wonder if they are actually supported
> by some newer receivers (mine is 4 years old). It'd be good if someone
> with a newish receiver could try the below :)
> To test this, one can run (replacing XX and YY with appropriate values
> from "aplay -L") on *sound git master*:
> speaker-test -c6 -Dhdmi:CARD=XX,DEV=YY -m FL,FR,RL,RR,FLH,FRH
> If you get some output for the RL/RR speakers, that should mean that
> 0x20+ CAs are supported. If there is no output except on FL/FR and there
> is proper output without the "-m FL,FR,RL,RR,FLH,FRH", this means that
> 0x20+ CAs are not supported.

We tested with Peter's Marantz NR1402 (introduced 2011), and it does
seem to support 0x20+ CAs (it drops unmappable channels, but doesn't
fall back to stereo only either so it clearly recognizes the mappings).

> I think there are about these options for us to take:
> a) drop 0x20+ CAs from channel_allocations altogether
> b) put the 0x20+ CAs under a module parameter
> c) only allow 0x20+ CAs if any CEA-861-E+ only speakers are specified
>    in EDID. However, as ELD doesn't have bits for these, we'd have to
>    employ some non-standard bits in ELD or communicate directly with
>    video driver.
> d) do nothing, allow the 0x20+ CAs.
> 
> IMHO we should do something, since players using ALSA channel mapping
> could just automatically select a manual channel map that uses an
> unsupported 0x20+ CA if the source audio stream contains such channels...

So I guess dropping them completely would be not be very nice... not
immediately sure what would be the best way forward, then, though...

> WDYT?
> 


-- 
Anssi Hannula

Re: [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[Takashi Iwai]

At Fri, 01 Nov 2013 23:43:12 +0200,
Anssi Hannula wrote:
> 
> Hi all!
> 
> Currently we allow the use of CA values up to 0x31 as defined in
> CEA-861-E/F. However, only CA values up to 0x19 are defined in
> CEA-861-B/C/D.
> 
> HDMI specification 1.4b specifies that the CA field is to be filled
> according to CEA-861-D, and DisplayPort 1.1a according to CEA-861-C.
> 
> The ELD (EDID-Like Data) format as specified by Intel HDA specification
> 1.0a has a speaker allocation bitmask that only accommodates speakers
> present in CEA-861-D; all of the 0x20+ CAs contain speakers that do not
> have a corresponding bit in ELD.
> 
> Using a CA value unsupported by sink will cause either a completely
> silent output or stereo output, so I think we should try to prevent
> selecting such channel maps, if feasible.
> 
> However, before doing anything, I wonder if they are actually supported
> by some newer receivers (mine is 4 years old). It'd be good if someone
> with a newish receiver could try the below :)
> To test this, one can run (replacing XX and YY with appropriate values
> from "aplay -L") on *sound git master*:
> speaker-test -c6 -Dhdmi:CARD=XX,DEV=YY -m FL,FR,RL,RR,FLH,FRH
> If you get some output for the RL/RR speakers, that should mean that
> 0x20+ CAs are supported. If there is no output except on FL/FR and there
> is proper output without the "-m FL,FR,RL,RR,FLH,FRH", this means that
> 0x20+ CAs are not supported.
> 
> I think there are about these options for us to take:
> a) drop 0x20+ CAs from channel_allocations altogether
> b) put the 0x20+ CAs under a module parameter
> c) only allow 0x20+ CAs if any CEA-861-E+ only speakers are specified
>    in EDID. However, as ELD doesn't have bits for these, we'd have to
>    employ some non-standard bits in ELD or communicate directly with
>    video driver.
> d) do nothing, allow the 0x20+ CAs.
> 
> IMHO we should do something, since players using ALSA channel mapping
> could just automatically select a manual channel map that uses an
> unsupported 0x20+ CA if the source audio stream contains such channels...
> 
> WDYT?

Practical options as of now are either (b) or (d).

Extending EDID in a non-standard way is no-go.  Better to put finger
away.  OTOH, if we're going to that direction, we should rather build
a better / more direct communication way with the graphics driver,
instead.  This would make things in Intel graphics easier, too, for
example.

And (a) isn't the best option, obviously.

Now the question is whether (b) or (d).  Can 0x20+ CA be chosen by
default from any applications without extra setup?  If it can be done
only via user's manual configuration or option, it's essentially
user's responsibility.  If so, adding an option to the module is
nothing but one more annoyance.  Then I'd take (d).

If 0x20+ can be selected automatically in some situations, it'd make
sense to block it as default, so (b) would be the choice.  But I guess
it won't happen normally.


thanks,

Takashi

Re: [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[Anssi Hannula]

05.11.2013 15:43, Takashi Iwai kirjoitti:
> At Fri, 01 Nov 2013 23:43:12 +0200,
> Anssi Hannula wrote:
>>
>> Hi all!
>>
>> Currently we allow the use of CA values up to 0x31 as defined in
>> CEA-861-E/F. However, only CA values up to 0x19 are defined in
>> CEA-861-B/C/D.
>>
>> HDMI specification 1.4b specifies that the CA field is to be filled
>> according to CEA-861-D, and DisplayPort 1.1a according to CEA-861-C.
>>
>> The ELD (EDID-Like Data) format as specified by Intel HDA specification
>> 1.0a has a speaker allocation bitmask that only accommodates speakers
>> present in CEA-861-D; all of the 0x20+ CAs contain speakers that do not
>> have a corresponding bit in ELD.
>>
>> Using a CA value unsupported by sink will cause either a completely
>> silent output or stereo output, so I think we should try to prevent
>> selecting such channel maps, if feasible.
>>
>> However, before doing anything, I wonder if they are actually supported
>> by some newer receivers (mine is 4 years old). It'd be good if someone
>> with a newish receiver could try the below :)
>> To test this, one can run (replacing XX and YY with appropriate values
>> from "aplay -L") on *sound git master*:
>> speaker-test -c6 -Dhdmi:CARD=XX,DEV=YY -m FL,FR,RL,RR,FLH,FRH
>> If you get some output for the RL/RR speakers, that should mean that
>> 0x20+ CAs are supported. If there is no output except on FL/FR and there
>> is proper output without the "-m FL,FR,RL,RR,FLH,FRH", this means that
>> 0x20+ CAs are not supported.
>>
>> I think there are about these options for us to take:
>> a) drop 0x20+ CAs from channel_allocations altogether
>> b) put the 0x20+ CAs under a module parameter
>> c) only allow 0x20+ CAs if any CEA-861-E+ only speakers are specified
>>    in EDID. However, as ELD doesn't have bits for these, we'd have to
>>    employ some non-standard bits in ELD or communicate directly with
>>    video driver.
>> d) do nothing, allow the 0x20+ CAs.
>>
>> IMHO we should do something, since players using ALSA channel mapping
>> could just automatically select a manual channel map that uses an
>> unsupported 0x20+ CA if the source audio stream contains such channels...
>>
>> WDYT?
> 
> Practical options as of now are either (b) or (d).
> 
> Extending EDID in a non-standard way is no-go.  Better to put finger
> away.  OTOH, if we're going to that direction, we should rather build
> a better / more direct communication way with the graphics driver,
> instead.  This would make things in Intel graphics easier, too, for
> example.

Yeah, another benefit of that would be getting the sink
manufacturer/product/name etc on the older (i.e. all but the very
latest) ATI/AMD cards. Of course that is a rather limited benefit, and
I'm not sure this 0x20+ CAs stuff is worth it either...

> And (a) isn't the best option, obviously.
> 
> Now the question is whether (b) or (d).  Can 0x20+ CA be chosen by
> default from any applications without extra setup?  If it can be done
> only via user's manual configuration or option, it's essentially
> user's responsibility.  If so, adding an option to the module is
> nothing but one more annoyance.  Then I'd take (d).
> 
> If 0x20+ can be selected automatically in some situations, it'd make
> sense to block it as default, so (b) would be the choice.  But I guess
> it won't happen normally.

Well, I guess not many applications have ALSA chmap support yet, so the
answer is "not chosen by default" for now.

I'm going to probably be writing ALSA chmap support for XBMC, and I will
probably try to set a channel map according to the source audio stream
channel map (if possible) to avoid software remapping, though. I don't
have the exact behavior planned out yet, though, but unless 0x20+ CAs
are blocked by ALSA, I think I'll just avoid using the E+ speaker
positions by default for HDMI in XBMC ALSA code.

For the record, the E+ speaker positions are FLH, FRH, FCH, FLW, FRW,
TC, so they aren't very common. And since HDMI 1.x supports just 8 PCM
channels, using those in discrete PCM mode means dropping some of the
standard 7.1 speakers (passthrough is of course a different story).

Also, even though Peter's receiver accepted the CAs, the receiver
channel mapping was somewhat weird (e.g. front wide channels were mapped
to rear speakers).

I guess I'm leaning towards (d)...

-- 
Anssi Hannula

Re: [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+

[Anssi Hannula]

05.11.2013 16:18, Anssi Hannula kirjoitti:
> 05.11.2013 15:43, Takashi Iwai kirjoitti:
>> At Fri, 01 Nov 2013 23:43:12 +0200,
>> Anssi Hannula wrote:
>>>
>>> Hi all!
>>>
>>> Currently we allow the use of CA values up to 0x31 as defined in
>>> CEA-861-E/F. However, only CA values up to 0x19 are defined in
>>> CEA-861-B/C/D.
>>>
>>> HDMI specification 1.4b specifies that the CA field is to be filled
>>> according to CEA-861-D, and DisplayPort 1.1a according to CEA-861-C.
>>>
>>> The ELD (EDID-Like Data) format as specified by Intel HDA specification
>>> 1.0a has a speaker allocation bitmask that only accommodates speakers
>>> present in CEA-861-D; all of the 0x20+ CAs contain speakers that do not
>>> have a corresponding bit in ELD.
>>>
>>> Using a CA value unsupported by sink will cause either a completely
>>> silent output or stereo output, so I think we should try to prevent
>>> selecting such channel maps, if feasible.
>>>
>>> However, before doing anything, I wonder if they are actually supported
>>> by some newer receivers (mine is 4 years old). It'd be good if someone
>>> with a newish receiver could try the below :)
>>> To test this, one can run (replacing XX and YY with appropriate values
>>> from "aplay -L") on *sound git master*:
>>> speaker-test -c6 -Dhdmi:CARD=XX,DEV=YY -m FL,FR,RL,RR,FLH,FRH
>>> If you get some output for the RL/RR speakers, that should mean that
>>> 0x20+ CAs are supported. If there is no output except on FL/FR and there
>>> is proper output without the "-m FL,FR,RL,RR,FLH,FRH", this means that
>>> 0x20+ CAs are not supported.
>>>
>>> I think there are about these options for us to take:
>>> a) drop 0x20+ CAs from channel_allocations altogether
>>> b) put the 0x20+ CAs under a module parameter
>>> c) only allow 0x20+ CAs if any CEA-861-E+ only speakers are specified
>>>    in EDID. However, as ELD doesn't have bits for these, we'd have to
>>>    employ some non-standard bits in ELD or communicate directly with
>>>    video driver.
>>> d) do nothing, allow the 0x20+ CAs.
>>>
>>> IMHO we should do something, since players using ALSA channel mapping
>>> could just automatically select a manual channel map that uses an
>>> unsupported 0x20+ CA if the source audio stream contains such channels...
>>>
>>> WDYT?
>>
>> Practical options as of now are either (b) or (d).
>>
>> Extending EDID in a non-standard way is no-go.  Better to put finger
>> away.  OTOH, if we're going to that direction, we should rather build
>> a better / more direct communication way with the graphics driver,
>> instead.  This would make things in Intel graphics easier, too, for
>> example.
> 
> Yeah, another benefit of that would be getting the sink
> manufacturer/product/name etc on the older (i.e. all but the very
> latest) ATI/AMD cards. Of course that is a rather limited benefit, and
> I'm not sure this 0x20+ CAs stuff is worth it either...

BTW, regarding ELD from HDA spec:
"Vendor Defined Block:
The vendor defined block of the ELD memory structure byte offset starts
from 4 + Baseline_ELD_Len * 4 to ELD buffer size – 1. This structure is
vendor specific. OS class driver will not interpret this block. Only the
associated vendor defined graphic/audio driver will be able to
understand and enumerate these features based on the specific vendor ELD
version number."

So it is valid to have vendor-defined data in the end of ELD, so we
could put an extended speaker mask for CEA-861-E+ positions there, which
we could use to determine if E+ chmaps should be allowed.
Though there are some problems with this approach (wouldn't work
directly with AMD/ATI nor with 3rdparty video drivers)...

I'm not saying this is a better option than the others, just wanted to
add this for the record :)

>> And (a) isn't the best option, obviously.
>>
>> Now the question is whether (b) or (d).  Can 0x20+ CA be chosen by
>> default from any applications without extra setup?  If it can be done
>> only via user's manual configuration or option, it's essentially
>> user's responsibility.  If so, adding an option to the module is
>> nothing but one more annoyance.  Then I'd take (d).
>>
>> If 0x20+ can be selected automatically in some situations, it'd make
>> sense to block it as default, so (b) would be the choice.  But I guess
>> it won't happen normally.
> 
> Well, I guess not many applications have ALSA chmap support yet, so the
> answer is "not chosen by default" for now.
> 
> I'm going to probably be writing ALSA chmap support for XBMC, and I will
> probably try to set a channel map according to the source audio stream
> channel map (if possible) to avoid software remapping, though. I don't
> have the exact behavior planned out yet, though, but unless 0x20+ CAs
> are blocked by ALSA, I think I'll just avoid using the E+ speaker
> positions by default for HDMI in XBMC ALSA code.
> 
> For the record, the E+ speaker positions are FLH, FRH, FCH, FLW, FRW,
> TC, so they aren't very common. And since HDMI 1.x supports just 8 PCM
> channels, using those in discrete PCM mode means dropping some of the
> standard 7.1 speakers (passthrough is of course a different story).
> 
> Also, even though Peter's receiver accepted the CAs, the receiver
> channel mapping was somewhat weird (e.g. front wide channels were mapped
> to rear speakers).
> 
> I guess I'm leaning towards (d)...
> 


-- 
Anssi Hannula