All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.