alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@iki.fi>
To: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>, Fengguang Wu <fengguang.wu@intel.com>
Subject: [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+
Date: Fri, 01 Nov 2013 23:43:12 +0200	[thread overview]
Message-ID: <52742070.1080904@iki.fi> (raw)

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

             reply	other threads:[~2013-11-01 21:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 21:43 Anssi Hannula [this message]
2013-11-02 15:29 ` [RFC/RFT] HDMI/DP CEA-861-E+ channel allocations 0x20+ Anssi Hannula
2013-11-05 13:43 ` Takashi Iwai
2013-11-05 14:18   ` Anssi Hannula
2013-11-10  5:15     ` Anssi Hannula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52742070.1080904@iki.fi \
    --to=anssi.hannula@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=fengguang.wu@intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).