[alsa-devel] [PATCH v3 0/5] ALSA: hda - hdmi: ATI/AMD multi-channel and HBR support
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes: - added customizable callbacks instead of polluting generic code - fixed wrong codec id in rev3+ check (as previously noted) - cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
Anssi Hannula (5): ALSA: hda - hdmi: Allow HDA patches to customize more operations ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs
sound/pci/hda/hda_eld.c | 151 +++++++++++ sound/pci/hda/hda_local.h | 4 + sound/pci/hda/patch_hdmi.c | 643 +++++++++++++++++++++++++++++++++++++-------- 3 files changed, 689 insertions(+), 109 deletions(-)
Upcoming AMD multichannel support requires many customized operations (channel mapping, ELD, HBR) but can otherwise share most of its code with the generic patch.
Add a local struct hdmi_ops containing customizable HDMI-specific callbacks and move the current code to those callbacks. Functionality is unaltered.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi --- sound/pci/hda/patch_hdmi.c | 275 ++++++++++++++++++++++++++++++++------------- 1 file changed, 195 insertions(+), 80 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index a1fe4bb..b11cbe0 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -82,6 +82,39 @@ struct hdmi_spec_per_pin { #endif };
+struct cea_channel_speaker_allocation; + +/* operations used by generic code that can be overridden by patches */ +struct hdmi_ops { + int (*pin_get_eld)(struct hda_codec *codec, hda_nid_t pin_nid, + unsigned char *buf, int *eld_size); + + /* get and set channel assigned to each HDMI ASP (audio sample packet) slot */ + int (*pin_get_slot_channel)(struct hda_codec *codec, hda_nid_t pin_nid, + int asp_slot); + int (*pin_set_slot_channel)(struct hda_codec *codec, hda_nid_t pin_nid, + int asp_slot, int channel); + + void (*pin_setup_infoframe)(struct hda_codec *codec, hda_nid_t pin_nid, + int ca, int active_channels, int conn_type); + + /* enable/disable HBR (HD passthrough) */ + int (*pin_hbr_setup)(struct hda_codec *codec, hda_nid_t pin_nid, bool hbr); + + int (*setup_stream)(struct hda_codec *codec, hda_nid_t cvt_nid, + hda_nid_t pin_nid, u32 stream_tag, int format); + + /* Helpers for producing the channel map TLVs. These can be overridden + * for devices that have non-standard mapping requirements. */ + int (*chmap_cea_alloc_validate_get_type)(struct cea_channel_speaker_allocation *cap, + int channels); + void (*cea_alloc_to_tlv_chmap)(struct cea_channel_speaker_allocation *cap, + unsigned int *chmap, int channels); + + /* check that the user-given chmap is supported */ + int (*chmap_validate)(int ca, int channels, unsigned char *chmap); +}; + struct hdmi_spec { int num_cvts; struct snd_array cvts; /* struct hdmi_spec_per_cvt */ @@ -93,6 +126,7 @@ struct hdmi_spec { unsigned int channels_max; /* max over all cvts */
struct hdmi_eld temp_eld; + struct hdmi_ops ops; /* * Non-generic ATI/NVIDIA specific */ @@ -648,24 +682,24 @@ static void hdmi_debug_channel_mapping(struct hda_codec *codec, hda_nid_t pin_nid) { #ifdef CONFIG_SND_DEBUG_VERBOSE + struct hdmi_spec *spec = codec->spec; int i; - int slot; + int channel;
for (i = 0; i < 8; i++) { - slot = snd_hda_codec_read(codec, pin_nid, 0, - AC_VERB_GET_HDMI_CHAN_SLOT, i); + channel = spec->ops.pin_get_slot_channel(codec, pin_nid, i); printk(KERN_DEBUG "HDMI: ASP channel %d => slot %d\n", - slot >> 4, slot & 0xf); + channel, i); } #endif }
- static void hdmi_std_setup_channel_mapping(struct hda_codec *codec, hda_nid_t pin_nid, bool non_pcm, int ca) { + struct hdmi_spec *spec = codec->spec; struct cea_channel_speaker_allocation *ch_alloc; int i; int err; @@ -698,9 +732,10 @@ static void hdmi_std_setup_channel_mapping(struct hda_codec *codec, }
for (i = 0; i < 8; i++) { - err = snd_hda_codec_write(codec, pin_nid, 0, - AC_VERB_SET_HDMI_CHAN_SLOT, - non_pcm ? non_pcm_mapping[i] : hdmi_channel_mapping[ca][i]); + int slotsetup = non_pcm ? non_pcm_mapping[i] : hdmi_channel_mapping[ca][i]; + int hdmi_slot = slotsetup & 0x0f; + int channel = (slotsetup & 0xf0) >> 4; + err = spec->ops.pin_set_slot_channel(codec, pin_nid, hdmi_slot, channel); if (err) { snd_printdd(KERN_NOTICE "HDMI: channel mapping failed\n"); @@ -810,6 +845,7 @@ static int hdmi_manual_setup_channel_mapping(struct hda_codec *codec, int chs, unsigned char *map, int ca) { + struct hdmi_spec *spec = codec->spec; int ordered_ca = get_channel_allocation_order(ca); int alsa_pos, hdmi_slot; int assignments[8] = {[0 ... 7] = 0xf}; @@ -825,11 +861,10 @@ static int hdmi_manual_setup_channel_mapping(struct hda_codec *codec, }
for (hdmi_slot = 0; hdmi_slot < 8; hdmi_slot++) { - int val, err; + int err;
- val = (assignments[hdmi_slot] << 4) | hdmi_slot; - err = snd_hda_codec_write(codec, pin_nid, 0, - AC_VERB_SET_HDMI_CHAN_SLOT, val); + err = spec->ops.pin_set_slot_channel(codec, pin_nid, hdmi_slot, + assignments[hdmi_slot]); if (err) return -EINVAL; } @@ -865,6 +900,22 @@ static void hdmi_setup_channel_mapping(struct hda_codec *codec, hdmi_debug_channel_mapping(codec, pin_nid); }
+static int hdmi_pin_set_slot_channel(struct hda_codec *codec, hda_nid_t pin_nid, + int asp_slot, int channel) +{ + return snd_hda_codec_write(codec, pin_nid, 0, + AC_VERB_SET_HDMI_CHAN_SLOT, + (channel << 4) | asp_slot); +} + +static int hdmi_pin_get_slot_channel(struct hda_codec *codec, hda_nid_t pin_nid, + int asp_slot) +{ + return (snd_hda_codec_read(codec, pin_nid, 0, + AC_VERB_GET_HDMI_CHAN_SLOT, + asp_slot) & 0xf0) >> 4; +} + /* * Audio InfoFrame routines */ @@ -986,16 +1037,64 @@ static bool hdmi_infoframe_uptodate(struct hda_codec *codec, hda_nid_t pin_nid, return true; }
+static void hdmi_pin_setup_infoframe(struct hda_codec *codec, + hda_nid_t pin_nid, + int ca, int active_channels, + int conn_type) +{ + union audio_infoframe ai; + + if (conn_type == 0) { /* HDMI */ + struct hdmi_audio_infoframe *hdmi_ai = &ai.hdmi; + + hdmi_ai->type = 0x84; + hdmi_ai->ver = 0x01; + hdmi_ai->len = 0x0a; + hdmi_ai->CC02_CT47 = active_channels - 1; + hdmi_ai->CA = ca; + hdmi_checksum_audio_infoframe(hdmi_ai); + } else if (conn_type == 1) { /* DisplayPort */ + struct dp_audio_infoframe *dp_ai = &ai.dp; + + dp_ai->type = 0x84; + dp_ai->len = 0x1b; + dp_ai->ver = 0x11 << 2; + dp_ai->CC02_CT47 = active_channels - 1; + dp_ai->CA = ca; + } else { + snd_printd("HDMI: unknown connection type at pin %d\n", + pin_nid); + return; + } + + /* + * sizeof(ai) is used instead of sizeof(*hdmi_ai) or + * sizeof(*dp_ai) to avoid partial match/update problems when + * the user switches between HDMI/DP monitors. + */ + if (!hdmi_infoframe_uptodate(codec, pin_nid, ai.bytes, + sizeof(ai))) { + snd_printdd("hdmi_pin_setup_infoframe: " + "pin=%d channels=%d ca=0x%02x\n", + pin_nid, + active_channels, ca); + hdmi_stop_infoframe_trans(codec, pin_nid); + hdmi_fill_audio_infoframe(codec, pin_nid, + ai.bytes, sizeof(ai)); + hdmi_start_infoframe_trans(codec, pin_nid); + } +} + static void hdmi_setup_audio_infoframe(struct hda_codec *codec, struct hdmi_spec_per_pin *per_pin, bool non_pcm) { + struct hdmi_spec *spec = codec->spec; hda_nid_t pin_nid = per_pin->pin_nid; int channels = per_pin->channels; int active_channels; struct hdmi_eld *eld; int ca, ordered_ca; - union audio_infoframe ai;
if (!channels) return; @@ -1021,30 +1120,6 @@ static void hdmi_setup_audio_infoframe(struct hda_codec *codec,
hdmi_set_channel_count(codec, per_pin->cvt_nid, active_channels);
- memset(&ai, 0, sizeof(ai)); - if (eld->info.conn_type == 0) { /* HDMI */ - struct hdmi_audio_infoframe *hdmi_ai = &ai.hdmi; - - hdmi_ai->type = 0x84; - hdmi_ai->ver = 0x01; - hdmi_ai->len = 0x0a; - hdmi_ai->CC02_CT47 = active_channels - 1; - hdmi_ai->CA = ca; - hdmi_checksum_audio_infoframe(hdmi_ai); - } else if (eld->info.conn_type == 1) { /* DisplayPort */ - struct dp_audio_infoframe *dp_ai = &ai.dp; - - dp_ai->type = 0x84; - dp_ai->len = 0x1b; - dp_ai->ver = 0x11 << 2; - dp_ai->CC02_CT47 = active_channels - 1; - dp_ai->CA = ca; - } else { - snd_printd("HDMI: unknown connection type at pin %d\n", - pin_nid); - return; - } - /* * always configure channel mapping, it may have been changed by the * user in the meantime @@ -1053,27 +1128,12 @@ static void hdmi_setup_audio_infoframe(struct hda_codec *codec, channels, per_pin->chmap, per_pin->chmap_set);
- /* - * sizeof(ai) is used instead of sizeof(*hdmi_ai) or - * sizeof(*dp_ai) to avoid partial match/update problems when - * the user switches between HDMI/DP monitors. - */ - if (!hdmi_infoframe_uptodate(codec, pin_nid, ai.bytes, - sizeof(ai))) { - snd_printdd("hdmi_setup_audio_infoframe: " - "pin=%d channels=%d ca=0x%02x\n", - pin_nid, - active_channels, ca); - hdmi_stop_infoframe_trans(codec, pin_nid); - hdmi_fill_audio_infoframe(codec, pin_nid, - ai.bytes, sizeof(ai)); - hdmi_start_infoframe_trans(codec, pin_nid); - } + spec->ops.pin_setup_infoframe(codec, pin_nid, ca, active_channels, + eld->info.conn_type);
per_pin->non_pcm = non_pcm; }
- /* * Unsolicited events */ @@ -1176,26 +1236,22 @@ static void haswell_verify_D0(struct hda_codec *codec, #define is_hbr_format(format) \ ((format & AC_FMT_TYPE_NON_PCM) && (format & AC_FMT_CHAN_MASK) == 7)
-static int hdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid, - hda_nid_t pin_nid, u32 stream_tag, int format) +static int hdmi_pin_hbr_setup(struct hda_codec *codec, hda_nid_t pin_nid, + bool hbr) { - int pinctl; - int new_pinctl = 0; - - if (is_haswell(codec)) - haswell_verify_D0(codec, cvt_nid, pin_nid); + int pinctl, new_pinctl;
if (snd_hda_query_pin_caps(codec, pin_nid) & AC_PINCAP_HBR) { pinctl = snd_hda_codec_read(codec, pin_nid, 0, AC_VERB_GET_PIN_WIDGET_CONTROL, 0);
new_pinctl = pinctl & ~AC_PINCTL_EPT; - if (is_hbr_format(format)) + if (hbr) new_pinctl |= AC_PINCTL_EPT_HBR; else new_pinctl |= AC_PINCTL_EPT_NATIVE;
- snd_printdd("hdmi_setup_stream: " + snd_printdd("hdmi_pin_hbr_setup: " "NID=0x%x, %spinctl=0x%x\n", pin_nid, pinctl == new_pinctl ? "" : "new-", @@ -1205,11 +1261,26 @@ static int hdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid, snd_hda_codec_write(codec, pin_nid, 0, AC_VERB_SET_PIN_WIDGET_CONTROL, new_pinctl); + } else if (hbr) + return -EINVAL;
- } - if (is_hbr_format(format) && !new_pinctl) { + return 0; +} + +static int hdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid, + hda_nid_t pin_nid, u32 stream_tag, int format) +{ + struct hdmi_spec *spec = codec->spec; + int err; + + if (is_haswell(codec)) + haswell_verify_D0(codec, cvt_nid, pin_nid); + + err = spec->ops.pin_hbr_setup(codec, pin_nid, is_hbr_format(format)); + + if (err) { snd_printdd("hdmi_setup_stream: HBR is not supported\n"); - return -EINVAL; + return err; }
snd_hda_codec_setup_stream(codec, cvt_nid, stream_tag, 0, format); @@ -1424,7 +1495,7 @@ static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll) codec->addr, pin_nid, pin_eld->monitor_present, eld->eld_valid);
if (eld->eld_valid) { - if (snd_hdmi_get_eld(codec, pin_nid, eld->eld_buffer, + if (spec->ops.pin_get_eld(codec, pin_nid, eld->eld_buffer, &eld->eld_size) < 0) eld->eld_valid = false; else { @@ -1655,7 +1726,7 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, hdmi_setup_audio_infoframe(codec, per_pin, non_pcm); mutex_unlock(&per_pin->lock);
- return hdmi_setup_stream(codec, cvt_nid, pin_nid, stream_tag, format); + return spec->ops.setup_stream(codec, cvt_nid, pin_nid, stream_tag, format); }
static int generic_hdmi_playback_pcm_cleanup(struct hda_pcm_stream *hinfo, @@ -1727,6 +1798,34 @@ static int hdmi_chmap_ctl_info(struct snd_kcontrol *kcontrol, return 0; }
+static int hdmi_chmap_cea_alloc_validate_get_type(struct cea_channel_speaker_allocation *cap, + int channels) +{ + /* If the speaker allocation matches the channel count, it is OK.*/ + if (cap->channels != channels) + return -1; + + /* all channels are remappable freely */ + return SNDRV_CTL_TLVT_CHMAP_VAR; +} + +static void hdmi_cea_alloc_to_tlv_chmap(struct cea_channel_speaker_allocation *cap, + unsigned int *chmap, int channels) +{ + int count = 0; + int c; + + for (c = 7; c >= 0; c--) { + int spk = cap->speakers[c]; + if (!spk) + continue; + + chmap[count++] = spk_to_chmap(spk); + } + + WARN_ON(count != channels); +} + static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, unsigned int size, unsigned int __user *tlv) { @@ -1743,16 +1842,19 @@ static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, size -= 8; dst = tlv + 2; for (chs = 2; chs <= spec->channels_max; chs++) { - int i, c; + int i; struct cea_channel_speaker_allocation *cap; cap = channel_allocations; for (i = 0; i < ARRAY_SIZE(channel_allocations); i++, cap++) { int chs_bytes = chs * 4; - if (cap->channels != chs) + int type = spec->ops.chmap_cea_alloc_validate_get_type(cap, chs); + unsigned int tlv_chmap[8]; + + if (type < 0) continue; if (size < 8) return -ENOMEM; - if (put_user(SNDRV_CTL_TLVT_CHMAP_VAR, dst) || + if (put_user(type, dst) || put_user(chs_bytes, dst + 1)) return -EFAULT; dst += 2; @@ -1762,14 +1864,10 @@ static int hdmi_chmap_ctl_tlv(struct snd_kcontrol *kcontrol, int op_flag, return -ENOMEM; size -= chs_bytes; count += chs_bytes; - for (c = 7; c >= 0; c--) { - int spk = cap->speakers[c]; - if (!spk) - continue; - if (put_user(spk_to_chmap(spk), dst)) - return -EFAULT; - dst++; - } + spec->ops.cea_alloc_to_tlv_chmap(cap, tlv_chmap, chs); + if (copy_to_user(dst, tlv_chmap, chs_bytes)) + return -EFAULT; + dst += chs; } } if (put_user(count, tlv + 1)) @@ -1803,7 +1901,7 @@ static int hdmi_chmap_ctl_put(struct snd_kcontrol *kcontrol, unsigned int ctl_idx; struct snd_pcm_substream *substream; unsigned char chmap[8]; - int i, ca, prepared = 0; + int i, err, ca, prepared = 0;
ctl_idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); substream = snd_pcm_chmap_substream(info, ctl_idx); @@ -1827,6 +1925,11 @@ static int hdmi_chmap_ctl_put(struct snd_kcontrol *kcontrol, ca = hdmi_manual_channel_allocation(ARRAY_SIZE(chmap), chmap); if (ca < 0) return -EINVAL; + if (spec->ops.chmap_validate) { + err = spec->ops.chmap_validate(ca, ARRAY_SIZE(chmap), chmap); + if (err) + return err; + } mutex_lock(&per_pin->lock); per_pin->chmap_set = true; memcpy(per_pin->chmap, chmap, sizeof(chmap)); @@ -2033,6 +2136,17 @@ static const struct hda_codec_ops generic_hdmi_patch_ops = { #endif };
+static const struct hdmi_ops generic_standard_hdmi_ops = { + .pin_get_eld = snd_hdmi_get_eld, + .pin_get_slot_channel = hdmi_pin_get_slot_channel, + .pin_set_slot_channel = hdmi_pin_set_slot_channel, + .pin_setup_infoframe = hdmi_pin_setup_infoframe, + .pin_hbr_setup = hdmi_pin_hbr_setup, + .setup_stream = hdmi_setup_stream, + .chmap_cea_alloc_validate_get_type = hdmi_chmap_cea_alloc_validate_get_type, + .cea_alloc_to_tlv_chmap = hdmi_cea_alloc_to_tlv_chmap, +}; +
static void intel_haswell_fixup_connect_list(struct hda_codec *codec, hda_nid_t nid) @@ -2115,6 +2229,7 @@ static int patch_generic_hdmi(struct hda_codec *codec) if (spec == NULL) return -ENOMEM;
+ spec->ops = generic_standard_hdmi_ops; codec->spec = spec; hdmi_array_init(spec, 4);
ATI/AMD codecs do not support all the standard HDA HDMI/DP functions, instead various vendor-specific verbs are provided.
This commit addresses these missing functions: - standard channel mapping support - standard infoframe configuration support
ATI/AMD provides their own verbs that allow the following: - setting CA for infoframe - setting down-mix information for infoframe - channel pair remapping - individual channel remapping (revision ID 3+, 0x100300+)
The documentation for the verbs has now been released by AMD: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
Add support for the ATI/AMD specific verbs and use them instead of the generic methods on ATI/AMD codecs. This allows multi-channel PCM audio to work.
Channel remapping is restricted to pairwise mapping on codecs with revision ID 2 (0x100200 as reported by procfs codec#X) or lower. This means cards up to Radeon HD7670 as far as I know. This will not affect standard multi-channel modes since these codecs support automatic FC-LFE swapping for HDMI.
ATI/AMD codecs do not advertise all of their supported rates, formats and channel counts, therefore that information is forced accordingly so that all HDMI 1.x PCM parameters are marked as supported.
Support for multiple ports is also added to patch_atihdmi so that 0x1002aa01 codecs with multiple ports will work properly when switched back to that patch.
v2: splitted ELD emulation to a separate patch, tlv fixes v3: adapted to the new hdmi_ops infrastructure, fixed rev3+ vendor id
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Peter Frühberger fritsch@xbmc.org # v2 Tested-by: Olivier Langlois olivier@trillion01.com # v2+rev3fix --- sound/pci/hda/patch_hdmi.c | 302 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 273 insertions(+), 29 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index b11cbe0..4ef5676 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -6,6 +6,7 @@ * Copyright (c) 2006 ATI Technologies Inc. * Copyright (c) 2008 NVIDIA Corp. All rights reserved. * Copyright (c) 2008 Wei Ni wni@nvidia.com + * Copyright (c) 2013 Anssi Hannula anssi.hannula@iki.fi * * Authors: * Wu Fengguang wfg@linux.intel.com @@ -128,7 +129,7 @@ struct hdmi_spec { struct hdmi_eld temp_eld; struct hdmi_ops ops; /* - * Non-generic ATI/NVIDIA specific + * Non-generic VIA/NVIDIA specific */ struct hda_multi_out multiout; struct hda_pcm_stream pcm_playback; @@ -2785,49 +2786,292 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) }
/* - * ATI-specific implementations - * - * FIXME: we may omit the whole this and use the generic code once after - * it's confirmed to work. + * ATI/AMD-specific implementations */
-#define ATIHDMI_CVT_NID 0x02 /* audio converter */ -#define ATIHDMI_PIN_NID 0x03 /* HDMI output pin */ +#define is_amdhdmi_rev3_or_later(codec) \ + ((codec)->vendor_id == 0x1002aa01 && ((codec)->revision_id & 0xff00) >= 0x0300) +#define has_amd_full_remap_support(codec) is_amdhdmi_rev3_or_later(codec) + +/* ATI/AMD specific HDA pin verbs, see the AMD HDA Verbs specification */ +#define ATI_VERB_SET_CHANNEL_ALLOCATION 0x771 +#define ATI_VERB_SET_DOWNMIX_INFO 0x772 +#define ATI_VERB_SET_MULTICHANNEL_01 0x777 +#define ATI_VERB_SET_MULTICHANNEL_23 0x778 +#define ATI_VERB_SET_MULTICHANNEL_45 0x779 +#define ATI_VERB_SET_MULTICHANNEL_67 0x77a +#define ATI_VERB_SET_MULTICHANNEL_1 0x785 +#define ATI_VERB_SET_MULTICHANNEL_3 0x786 +#define ATI_VERB_SET_MULTICHANNEL_5 0x787 +#define ATI_VERB_SET_MULTICHANNEL_7 0x788 +#define ATI_VERB_SET_MULTICHANNEL_MODE 0x789 +#define ATI_VERB_GET_CHANNEL_ALLOCATION 0xf71 +#define ATI_VERB_GET_DOWNMIX_INFO 0xf72 +#define ATI_VERB_GET_MULTICHANNEL_01 0xf77 +#define ATI_VERB_GET_MULTICHANNEL_23 0xf78 +#define ATI_VERB_GET_MULTICHANNEL_45 0xf79 +#define ATI_VERB_GET_MULTICHANNEL_67 0xf7a +#define ATI_VERB_GET_MULTICHANNEL_1 0xf85 +#define ATI_VERB_GET_MULTICHANNEL_3 0xf86 +#define ATI_VERB_GET_MULTICHANNEL_5 0xf87 +#define ATI_VERB_GET_MULTICHANNEL_7 0xf88 +#define ATI_VERB_GET_MULTICHANNEL_MODE 0xf89 + +#define ATI_OUT_ENABLE 0x1 + +#define ATI_MULTICHANNEL_MODE_PAIRED 0 +#define ATI_MULTICHANNEL_MODE_SINGLE 1 + +static void atihdmi_pin_setup_infoframe(struct hda_codec *codec, hda_nid_t pin_nid, int ca, + int active_channels, int conn_type) +{ + snd_hda_codec_write(codec, pin_nid, 0, ATI_VERB_SET_CHANNEL_ALLOCATION, ca); +} + +static int atihdmi_paired_swap_fc_lfe(int pos) +{ + /* + * ATI/AMD have automatic FC/LFE swap built-in + * when in pairwise mapping mode. + */ + + switch (pos) { + /* see channel_allocations[].speakers[] */ + case 2: return 3; + case 3: return 2; + default: break; + } + + return pos; +} + +static int atihdmi_paired_chmap_validate(int ca, int chs, unsigned char *map) +{ + struct cea_channel_speaker_allocation *cap; + int i, j; + + /* check that only channel pairs need to be remapped on old pre-rev3 ATI/AMD */ + + cap = &channel_allocations[get_channel_allocation_order(ca)]; + for (i = 0; i < chs; ++i) { + int mask = to_spk_mask(map[i]); + bool ok = false; + bool companion_ok = false; + + if (!mask) + continue; + + for (j = 0 + i % 2; j < 8; j += 2) { + int chan_idx = 7 - atihdmi_paired_swap_fc_lfe(j); + if (cap->speakers[chan_idx] == mask) { + /* channel is in a supported position */ + ok = true; + + if (i % 2 == 0 && i + 1 < chs) { + /* even channel, check the odd companion */ + int comp_chan_idx = 7 - atihdmi_paired_swap_fc_lfe(j + 1); + int comp_mask_req = to_spk_mask(map[i+1]); + int comp_mask_act = cap->speakers[comp_chan_idx]; + + if (comp_mask_req == comp_mask_act) + companion_ok = true; + else + return -EINVAL; + } + break; + } + } + + if (!ok) + return -EINVAL; + + if (companion_ok) + i++; /* companion channel already checked */ + } + + return 0; +} + +static int atihdmi_pin_set_slot_channel(struct hda_codec *codec, hda_nid_t pin_nid, + int hdmi_slot, int stream_channel) +{ + int verb; + int ati_channel_setup = 0; + + if (hdmi_slot > 7) + return -EINVAL; + + if (!has_amd_full_remap_support(codec)) { + hdmi_slot = atihdmi_paired_swap_fc_lfe(hdmi_slot); + + /* In case this is an odd slot but without stream channel, do not + * disable the slot since the corresponding even slot could have a + * channel. In case neither have a channel, the slot pair will be + * disabled when this function is called for the even slot. */ + if (hdmi_slot % 2 != 0 && stream_channel == 0xf) + return 0; + + hdmi_slot -= hdmi_slot % 2; + + if (stream_channel != 0xf) + stream_channel -= stream_channel % 2; + } + + verb = ATI_VERB_SET_MULTICHANNEL_01 + hdmi_slot/2 + (hdmi_slot % 2) * 0x00e; + + /* ati_channel_setup format: [7..4] = stream_channel_id, [1] = mute, [0] = enable */ + + if (stream_channel != 0xf) + ati_channel_setup = (stream_channel << 4) | ATI_OUT_ENABLE; + + return snd_hda_codec_write(codec, pin_nid, 0, verb, ati_channel_setup); +} + +static int atihdmi_pin_get_slot_channel(struct hda_codec *codec, hda_nid_t pin_nid, + int asp_slot) +{ + bool was_odd = false; + int ati_asp_slot = asp_slot; + int verb; + int ati_channel_setup; + + if (asp_slot > 7) + return -EINVAL; + + if (!has_amd_full_remap_support(codec)) { + ati_asp_slot = atihdmi_paired_swap_fc_lfe(asp_slot); + if (ati_asp_slot % 2 != 0) { + ati_asp_slot -= 1; + was_odd = true; + } + } + + verb = ATI_VERB_GET_MULTICHANNEL_01 + ati_asp_slot/2 + (ati_asp_slot % 2) * 0x00e; + + ati_channel_setup = snd_hda_codec_read(codec, pin_nid, 0, verb, 0); + + if (!(ati_channel_setup & ATI_OUT_ENABLE)) + return 0xf; + + return ((ati_channel_setup & 0xf0) >> 4) + !!was_odd; +}
-static int atihdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, - struct hda_codec *codec, - unsigned int stream_tag, - unsigned int format, - struct snd_pcm_substream *substream) +static int atihdmi_paired_chmap_cea_alloc_validate_get_type(struct cea_channel_speaker_allocation *cap, + int channels) +{ + int c; + + /* + * Pre-rev3 ATI/AMD codecs operate in a paired channel mode, so + * we need to take that into account (a single channel may take 2 + * channel slots if we need to carry a silent channel next to it). + * On Rev3+ AMD codecs this function is not used. + */ + int chanpairs = 0; + + /* We only produce even-numbered channel count TLVs */ + if ((channels % 2) != 0) + return -1; + + for (c = 0; c < 7; c += 2) { + if (cap->speakers[c] || cap->speakers[c+1]) + chanpairs++; + } + + if (chanpairs * 2 != channels) + return -1; + + return SNDRV_CTL_TLVT_CHMAP_PAIRED; +} + +static void atihdmi_paired_cea_alloc_to_tlv_chmap(struct cea_channel_speaker_allocation *cap, + unsigned int *chmap, int channels) +{ + /* produce paired maps for pre-rev3 ATI/AMD codecs */ + int count = 0; + int c; + + for (c = 7; c >= 0; c--) { + int chan = 7 - atihdmi_paired_swap_fc_lfe(7 - c); + int spk = cap->speakers[chan]; + if (!spk) { + /* add N/A channel if the companion channel is occupied */ + if (cap->speakers[chan + (chan % 2 ? -1 : 1)]) + chmap[count++] = SNDRV_CHMAP_NA; + + continue; + } + + chmap[count++] = spk_to_chmap(spk); + } + + WARN_ON(count != channels); +} + +static int atihdmi_init(struct hda_codec *codec) { struct hdmi_spec *spec = codec->spec; - struct hdmi_spec_per_cvt *per_cvt = get_cvt(spec, 0); - int chans = substream->runtime->channels; - int i, err; + int pin_idx, err;
- err = simple_playback_pcm_prepare(hinfo, codec, stream_tag, format, - substream); - if (err < 0) + err = generic_hdmi_init(codec); + + if (err) return err; - snd_hda_codec_write(codec, per_cvt->cvt_nid, 0, - AC_VERB_SET_CVT_CHAN_COUNT, chans - 1); - /* FIXME: XXX */ - for (i = 0; i < chans; i++) { - snd_hda_codec_write(codec, per_cvt->cvt_nid, 0, - AC_VERB_SET_HDMI_CHAN_SLOT, - (i << 4) | i); + + for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { + struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx); + + /* make sure downmix information in infoframe is zero */ + snd_hda_codec_write(codec, per_pin->pin_nid, 0, ATI_VERB_SET_DOWNMIX_INFO, 0); + + /* enable channel-wise remap mode if supported */ + if (has_amd_full_remap_support(codec)) + snd_hda_codec_write(codec, per_pin->pin_nid, 0, + ATI_VERB_SET_MULTICHANNEL_MODE, + ATI_MULTICHANNEL_MODE_SINGLE); } + return 0; }
static int patch_atihdmi(struct hda_codec *codec) { struct hdmi_spec *spec; - int err = patch_simple_hdmi(codec, ATIHDMI_CVT_NID, ATIHDMI_PIN_NID); - if (err < 0) + struct hdmi_spec_per_cvt *per_cvt; + int err, cvt_idx; + + err = patch_generic_hdmi(codec); + + if (err) return err; + + codec->patch_ops.init = atihdmi_init; + spec = codec->spec; - spec->pcm_playback.ops.prepare = atihdmi_playback_pcm_prepare; + + spec->ops.pin_get_slot_channel = atihdmi_pin_get_slot_channel; + spec->ops.pin_set_slot_channel = atihdmi_pin_set_slot_channel; + spec->ops.pin_setup_infoframe = atihdmi_pin_setup_infoframe; + + if (!has_amd_full_remap_support(codec)) { + /* override to ATI/AMD-specific versions with pairwise mapping */ + spec->ops.chmap_cea_alloc_validate_get_type = + atihdmi_paired_chmap_cea_alloc_validate_get_type; + spec->ops.cea_alloc_to_tlv_chmap = atihdmi_paired_cea_alloc_to_tlv_chmap; + spec->ops.chmap_validate = atihdmi_paired_chmap_validate; + } + + /* ATI/AMD converters do not advertise all of their capabilities */ + for (cvt_idx = 0; cvt_idx < spec->num_cvts; cvt_idx++) { + per_cvt = get_cvt(spec, cvt_idx); + per_cvt->channels_max = max(per_cvt->channels_max, 8u); + per_cvt->rates |= SUPPORTED_RATES; + per_cvt->formats |= SUPPORTED_FORMATS; + per_cvt->maxbps = max(per_cvt->maxbps, 24u); + } + + spec->channels_max = max(spec->channels_max, 8u); + return 0; }
@@ -2847,7 +3091,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = { { .id = 0x1002793c, .name = "RS600 HDMI", .patch = patch_atihdmi }, { .id = 0x10027919, .name = "RS600 HDMI", .patch = patch_atihdmi }, { .id = 0x1002791a, .name = "RS690/780 HDMI", .patch = patch_atihdmi }, -{ .id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi }, +{ .id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_atihdmi }, { .id = 0x10951390, .name = "SiI1390 HDMI", .patch = patch_generic_hdmi }, { .id = 0x10951392, .name = "SiI1392 HDMI", .patch = patch_generic_hdmi }, { .id = 0x17e80047, .name = "Chrontel HDMI", .patch = patch_generic_hdmi },
ATI/AMD HDMI/DP codecs do not include standard HDA ELD (EDID-like data) support.
In place of providing access to an ELD buffer, various vendor-specific verbs are provided to provide the relevant information. Revision ID 3 and later (0x100300 as reported by procfs codec#X) have support for providing more information than the previous revisions (but only if supported by the display driver).
Generate ELD from the information provided by the vendor-specific verbs on ATI/AMD codecs.
The specification is available at: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
v2: moved code to hda_eld.c and cleaned it up v3: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Peter Frühberger fritsch@xbmc.org # v2 Tested-by: Olivier Langlois olivier@trillion01.com # v2 --- sound/pci/hda/hda_eld.c | 151 +++++++++++++++++++++++++++++++++++++++++++++ sound/pci/hda/hda_local.h | 4 ++ sound/pci/hda/patch_hdmi.c | 9 +++ 3 files changed, 164 insertions(+)
diff --git a/sound/pci/hda/hda_eld.c b/sound/pci/hda/hda_eld.c index f62356c..32d3e38 100644 --- a/sound/pci/hda/hda_eld.c +++ b/sound/pci/hda/hda_eld.c @@ -2,6 +2,7 @@ * Generic routines and proc interface for ELD(EDID Like Data) information * * Copyright(c) 2008 Intel Corporation. + * Copyright (c) 2013 Anssi Hannula anssi.hannula@iki.fi * * Authors: * Wu Fengguang wfg@linux.intel.com @@ -633,3 +634,153 @@ void snd_hdmi_eld_update_pcm_info(struct parsed_hdmi_eld *e, hinfo->maxbps = min(hinfo->maxbps, maxbps); hinfo->channels_max = min(hinfo->channels_max, channels_max); } + + +/* ATI/AMD specific stuff (ELD emulation) */ + +#define ATI_VERB_SET_AUDIO_DESCRIPTOR 0x776 +#define ATI_VERB_SET_SINK_INFO_INDEX 0x780 +#define ATI_VERB_GET_SPEAKER_ALLOCATION 0xf70 +#define ATI_VERB_GET_AUDIO_DESCRIPTOR 0xf76 +#define ATI_VERB_GET_AUDIO_VIDEO_DELAY 0xf7b +#define ATI_VERB_GET_SINK_INFO_INDEX 0xf80 +#define ATI_VERB_GET_SINK_INFO_DATA 0xf81 + +#define ATI_SPKALLOC_SPKALLOC 0x007f +#define ATI_SPKALLOC_TYPE_HDMI 0x0100 +#define ATI_SPKALLOC_TYPE_DISPLAYPORT 0x0200 + +/* first three bytes are just standard SAD */ +#define ATI_AUDIODESC_CHANNELS 0x00000007 +#define ATI_AUDIODESC_RATES 0x0000ff00 +#define ATI_AUDIODESC_LPCM_STEREO_RATES 0xff000000 + +/* in standard HDMI VSDB format */ +#define ATI_DELAY_VIDEO_LATENCY 0x000000ff +#define ATI_DELAY_AUDIO_LATENCY 0x0000ff00 + +enum ati_sink_info_idx { + ATI_INFO_IDX_MANUFACTURER_ID = 0, + ATI_INFO_IDX_PRODUCT_ID = 1, + ATI_INFO_IDX_SINK_DESC_LEN = 2, + ATI_INFO_IDX_PORT_ID_LOW = 3, + ATI_INFO_IDX_PORT_ID_HIGH = 4, + ATI_INFO_IDX_SINK_DESC_FIRST = 5, + ATI_INFO_IDX_SINK_DESC_LAST = 22, /* max len 18 bytes */ +}; + +int snd_hdmi_get_eld_ati(struct hda_codec *codec, hda_nid_t nid, + unsigned char *buf, int *eld_size, bool rev3_or_later) +{ + int spkalloc, ati_sad, aud_synch; + int sink_desc_len = 0; + int pos, i; + + /* ATI/AMD does not have ELD, emulate it */ + + spkalloc = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SPEAKER_ALLOCATION, 0); + + if (!spkalloc) { + snd_printd(KERN_INFO "HDMI ATI/AMD: no speaker allocation for ELD\n"); + return -EINVAL; + } + + memset(buf, 0, ELD_FIXED_BYTES + ELD_MAX_MNL + ELD_MAX_SAD * 3); + + /* version */ + buf[0] = ELD_VER_CEA_861D << 3; + + /* speaker allocation from EDID */ + buf[7] = spkalloc & ATI_SPKALLOC_SPKALLOC; + + /* is DisplayPort? */ + if (spkalloc & ATI_SPKALLOC_TYPE_DISPLAYPORT) + buf[5] |= 0x04; + + pos = ELD_FIXED_BYTES; + + if (rev3_or_later) { + int sink_info; + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_PORT_ID_LOW); + sink_info = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + put_unaligned_le32(sink_info, buf + 8); + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_PORT_ID_HIGH); + sink_info = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + put_unaligned_le32(sink_info, buf + 12); + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_MANUFACTURER_ID); + sink_info = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + put_unaligned_le16(sink_info, buf + 16); + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_PRODUCT_ID); + sink_info = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + put_unaligned_le16(sink_info, buf + 18); + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_SINK_DESC_LEN); + sink_desc_len = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + + if (sink_desc_len > ELD_MAX_MNL) { + snd_printd(KERN_INFO "HDMI ATI/AMD: Truncating HDMI sink description with length %d\n", + sink_desc_len); + sink_desc_len = ELD_MAX_MNL; + } + + buf[4] |= sink_desc_len; + + for (i = 0; i < sink_desc_len; i++) { + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_SINK_INFO_INDEX, ATI_INFO_IDX_SINK_DESC_FIRST + i); + buf[pos++] = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_SINK_INFO_DATA, 0); + } + } + + for (i = AUDIO_CODING_TYPE_LPCM; i <= AUDIO_CODING_TYPE_WMAPRO; i++) { + if (i == AUDIO_CODING_TYPE_SACD || i == AUDIO_CODING_TYPE_DST) + continue; /* not handled by ATI/AMD */ + + snd_hda_codec_write(codec, nid, 0, ATI_VERB_SET_AUDIO_DESCRIPTOR, i << 3); + ati_sad = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_AUDIO_DESCRIPTOR, 0); + + if (ati_sad & ATI_AUDIODESC_RATES) { + /* format is supported, copy SAD as-is */ + buf[pos++] = (ati_sad & 0x0000ff) >> 0; + buf[pos++] = (ati_sad & 0x00ff00) >> 8; + buf[pos++] = (ati_sad & 0xff0000) >> 16; + } + + if (i == AUDIO_CODING_TYPE_LPCM + && (ati_sad & ATI_AUDIODESC_LPCM_STEREO_RATES) + && (ati_sad & ATI_AUDIODESC_LPCM_STEREO_RATES) >> 16 != (ati_sad & ATI_AUDIODESC_RATES)) { + /* for PCM there is a separate stereo rate mask */ + buf[pos++] = ((ati_sad & 0x000000ff) & ~ATI_AUDIODESC_CHANNELS) | 0x1; + /* rates from the extra byte */ + buf[pos++] = (ati_sad & 0xff000000) >> 24; + buf[pos++] = (ati_sad & 0x00ff0000) >> 16; + } + } + + if (pos == ELD_FIXED_BYTES + sink_desc_len) { + snd_printd(KERN_INFO "HDMI ATI/AMD: no audio descriptors for ELD\n"); + return -EINVAL; + } + + aud_synch = snd_hda_codec_read(codec, nid, 0, ATI_VERB_GET_AUDIO_VIDEO_DELAY, 0); + if ((aud_synch & ATI_DELAY_VIDEO_LATENCY) && (aud_synch & ATI_DELAY_AUDIO_LATENCY)) { + int video_latency = (aud_synch & ATI_DELAY_VIDEO_LATENCY) - 1; + int audio_latency = ((aud_synch & ATI_DELAY_AUDIO_LATENCY) >> 8) - 1; + + if (video_latency > audio_latency) + buf[6] = min(video_latency - audio_latency, 0xfa); + } + + /* Baseline length */ + buf[2] = pos - 4; + + /* SAD count */ + buf[5] |= ((pos - ELD_FIXED_BYTES - sink_desc_len) / 3) << 4; + + *eld_size = pos; + + return 0; +} diff --git a/sound/pci/hda/hda_local.h b/sound/pci/hda/hda_local.h index 46cddd4..d398b64 100644 --- a/sound/pci/hda/hda_local.h +++ b/sound/pci/hda/hda_local.h @@ -763,6 +763,10 @@ void snd_hdmi_show_eld(struct parsed_hdmi_eld *e); void snd_hdmi_eld_update_pcm_info(struct parsed_hdmi_eld *e, struct hda_pcm_stream *hinfo);
+int snd_hdmi_get_eld_ati(struct hda_codec *codec, hda_nid_t nid, + unsigned char *buf, int *eld_size, + bool rev3_or_later); + #ifdef CONFIG_PROC_FS void snd_hdmi_print_eld_info(struct hdmi_eld *eld, struct snd_info_buffer *buffer); diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 4ef5676..75ba933 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2822,6 +2822,14 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_MULTICHANNEL_MODE_PAIRED 0 #define ATI_MULTICHANNEL_MODE_SINGLE 1
+static int atihdmi_pin_get_eld(struct hda_codec *codec, hda_nid_t nid, + unsigned char *buf, int *eld_size) +{ + /* call hda_eld.c ATI/AMD-specific function */ + return snd_hdmi_get_eld_ati(codec, nid, buf, eld_size, + is_amdhdmi_rev3_or_later(codec)); +} + static void atihdmi_pin_setup_infoframe(struct hda_codec *codec, hda_nid_t pin_nid, int ca, int active_channels, int conn_type) { @@ -3049,6 +3057,7 @@ static int patch_atihdmi(struct hda_codec *codec)
spec = codec->spec;
+ spec->ops.pin_get_eld = atihdmi_pin_get_eld; spec->ops.pin_get_slot_channel = atihdmi_pin_get_slot_channel; spec->ops.pin_set_slot_channel = atihdmi_pin_set_slot_channel; spec->ops.pin_setup_infoframe = atihdmi_pin_setup_infoframe;
ATI/AMD HDMI codecs do not include standard HDA HDMI HBR support (which is required for bitstreaming DTS-HD and Dolby TrueHD), instead they have custom verbs for checking and enabling it.
Add support for the ATI/AMD HDMI HBR verbs.
The specification is available at: http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf
v2: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Peter Frühberger fritsch@xbmc.org # v1 --- sound/pci/hda/patch_hdmi.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 75ba933..2c45591 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2800,6 +2800,7 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_VERB_SET_MULTICHANNEL_23 0x778 #define ATI_VERB_SET_MULTICHANNEL_45 0x779 #define ATI_VERB_SET_MULTICHANNEL_67 0x77a +#define ATI_VERB_SET_HBR_CONTROL 0x77c #define ATI_VERB_SET_MULTICHANNEL_1 0x785 #define ATI_VERB_SET_MULTICHANNEL_3 0x786 #define ATI_VERB_SET_MULTICHANNEL_5 0x787 @@ -2811,6 +2812,7 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_VERB_GET_MULTICHANNEL_23 0xf78 #define ATI_VERB_GET_MULTICHANNEL_45 0xf79 #define ATI_VERB_GET_MULTICHANNEL_67 0xf7a +#define ATI_VERB_GET_HBR_CONTROL 0xf7c #define ATI_VERB_GET_MULTICHANNEL_1 0xf85 #define ATI_VERB_GET_MULTICHANNEL_3 0xf86 #define ATI_VERB_GET_MULTICHANNEL_5 0xf87 @@ -2822,6 +2824,9 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_MULTICHANNEL_MODE_PAIRED 0 #define ATI_MULTICHANNEL_MODE_SINGLE 1
+#define ATI_HBR_CAPABLE 0x01 +#define ATI_HBR_ENABLE 0x10 + static int atihdmi_pin_get_eld(struct hda_codec *codec, hda_nid_t nid, unsigned char *buf, int *eld_size) { @@ -3016,6 +3021,35 @@ static void atihdmi_paired_cea_alloc_to_tlv_chmap(struct cea_channel_speaker_all WARN_ON(count != channels); }
+static int atihdmi_pin_hbr_setup(struct hda_codec *codec, hda_nid_t pin_nid, + bool hbr) +{ + int hbr_ctl, hbr_ctl_new; + + hbr_ctl = snd_hda_codec_read(codec, pin_nid, 0, ATI_VERB_GET_HBR_CONTROL, 0); + if (hbr_ctl & ATI_HBR_CAPABLE) { + if (hbr) + hbr_ctl_new = hbr_ctl | ATI_HBR_ENABLE; + else + hbr_ctl_new = hbr_ctl & ~ATI_HBR_ENABLE; + + snd_printdd("atihdmi_pin_hbr_setup: " + "NID=0x%x, %shbr-ctl=0x%x\n", + pin_nid, + hbr_ctl == hbr_ctl_new ? "" : "new-", + hbr_ctl_new); + + if (hbr_ctl != hbr_ctl_new) + snd_hda_codec_write(codec, pin_nid, 0, + ATI_VERB_SET_HBR_CONTROL, + hbr_ctl_new); + + } else if (hbr) + return -EINVAL; + + return 0; +} + static int atihdmi_init(struct hda_codec *codec) { struct hdmi_spec *spec = codec->spec; @@ -3061,6 +3095,7 @@ static int patch_atihdmi(struct hda_codec *codec) spec->ops.pin_get_slot_channel = atihdmi_pin_get_slot_channel; spec->ops.pin_set_slot_channel = atihdmi_pin_set_slot_channel; spec->ops.pin_setup_infoframe = atihdmi_pin_setup_infoframe; + spec->ops.pin_hbr_setup = atihdmi_pin_hbr_setup;
if (!has_amd_full_remap_support(codec)) { /* override to ATI/AMD-specific versions with pairwise mapping */
Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by procfs codec#0) have a configurable ramp-up/down functionality.
The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ) specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for non-PCM.
Apply the recommended values according to provided S/PDIF AES0 settings since ramp-up/down does not make sense for non-PCM.
v2: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Olivier Langlois olivier@trillion01.com # v1 --- sound/pci/hda/patch_hdmi.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 2c45591..74bd2e63ce 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2819,6 +2819,10 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_VERB_GET_MULTICHANNEL_7 0xf88 #define ATI_VERB_GET_MULTICHANNEL_MODE 0xf89
+/* AMD specific HDA cvt verbs */ +#define ATI_VERB_SET_RAMP_RATE 0x770 +#define ATI_VERB_GET_RAMP_RATE 0xf70 + #define ATI_OUT_ENABLE 0x1
#define ATI_MULTICHANNEL_MODE_PAIRED 0 @@ -3050,6 +3054,23 @@ static int atihdmi_pin_hbr_setup(struct hda_codec *codec, hda_nid_t pin_nid, return 0; }
+static int atihdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid, + hda_nid_t pin_nid, u32 stream_tag, int format) +{ + + if (is_amdhdmi_rev3_or_later(codec)) { + int ramp_rate = 180; /* default as per AMD spec */ + /* disable ramp-up/down for non-pcm as per AMD spec */ + if (format & AC_FMT_TYPE_NON_PCM) + ramp_rate = 0; + + snd_hda_codec_write(codec, cvt_nid, 0, ATI_VERB_SET_RAMP_RATE, ramp_rate); + } + + return hdmi_setup_stream(codec, cvt_nid, pin_nid, stream_tag, format); +} + + static int atihdmi_init(struct hda_codec *codec) { struct hdmi_spec *spec = codec->spec; @@ -3096,6 +3117,7 @@ static int patch_atihdmi(struct hda_codec *codec) spec->ops.pin_set_slot_channel = atihdmi_pin_set_slot_channel; spec->ops.pin_setup_infoframe = atihdmi_pin_setup_infoframe; spec->ops.pin_hbr_setup = atihdmi_pin_hbr_setup; + spec->ops.setup_stream = atihdmi_setup_stream;
if (!has_amd_full_remap_support(codec)) { /* override to ATI/AMD-specific versions with pairwise mapping */
24.10.2013 21:10, Anssi Hannula kirjoitti:
Recent AMD HDMI codecs (revision ID 3 and later, 0x100300 as reported by procfs codec#0) have a configurable ramp-up/down functionality.
The documentation ( http://www.x.org/docs/AMD/AMD_HDA_verbs_v2.pdf ) specifies that 180 ("180/256 =~ 0.7") is recommended for PCM and 0 for non-PCM.
Apply the recommended values according to provided S/PDIF AES0 settings since ramp-up/down does not make sense for non-PCM.
v2: adapted to hdmi_ops infrastructure
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Olivier Langlois olivier@trillion01.com # v1
Hmm, actually, re-reading mails reveals that Olivier didn't find the expected difference with this setting, except for "maybe slightly slower startup with AES0=6" (i.e. value 0, which is unexpected).
So maybe a) it makes too unnoticiable a difference, or b) only affects certain hardware (card and/or sink), or c) ramp-up/down is only triggered with the MUTE bit of ATI_VERB_SET_MULTICHANNEL_xx which is also rev3+ specific, but is not presently used by the driver, or something else.
So there's a significant chance setting ramp rate is useless for us ATM, but probably does not do actual harm either.
Takashi, I'll leave it to you whether to apply this one (if you apply, feel free to add to patch description e.g. "No actual playback difference has been found in testing, so possibly something more is needed for ramp-up/down.").
I guess I might investigate the ramp-up/down/MUTE-bit stuff more at some point, but probably not in the next few months...
sound/pci/hda/patch_hdmi.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 2c45591..74bd2e63ce 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2819,6 +2819,10 @@ static int patch_nvhdmi_8ch_7x(struct hda_codec *codec) #define ATI_VERB_GET_MULTICHANNEL_7 0xf88 #define ATI_VERB_GET_MULTICHANNEL_MODE 0xf89
+/* AMD specific HDA cvt verbs */ +#define ATI_VERB_SET_RAMP_RATE 0x770 +#define ATI_VERB_GET_RAMP_RATE 0xf70
#define ATI_OUT_ENABLE 0x1
#define ATI_MULTICHANNEL_MODE_PAIRED 0 @@ -3050,6 +3054,23 @@ static int atihdmi_pin_hbr_setup(struct hda_codec *codec, hda_nid_t pin_nid, return 0; }
+static int atihdmi_setup_stream(struct hda_codec *codec, hda_nid_t cvt_nid,
hda_nid_t pin_nid, u32 stream_tag, int format)+{
- if (is_amdhdmi_rev3_or_later(codec)) {
int ramp_rate = 180; /* default as per AMD spec *//* disable ramp-up/down for non-pcm as per AMD spec */if (format & AC_FMT_TYPE_NON_PCM)ramp_rate = 0;snd_hda_codec_write(codec, cvt_nid, 0, ATI_VERB_SET_RAMP_RATE, ramp_rate);- }
- return hdmi_setup_stream(codec, cvt_nid, pin_nid, stream_tag, format);
+}
static int atihdmi_init(struct hda_codec *codec) { struct hdmi_spec *spec = codec->spec; @@ -3096,6 +3117,7 @@ static int patch_atihdmi(struct hda_codec *codec) spec->ops.pin_set_slot_channel = atihdmi_pin_set_slot_channel; spec->ops.pin_setup_infoframe = atihdmi_pin_setup_infoframe; spec->ops.pin_hbr_setup = atihdmi_pin_hbr_setup;
spec->ops.setup_stream = atihdmi_setup_stream;
if (!has_amd_full_remap_support(codec)) { /* override to ATI/AMD-specific versions with pairwise mapping */
24.10.2013 21:10, Anssi Hannula kirjoitti:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Aand that would be http://onse.fi/files/atihdmi6.patch not 5.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
On Thu, 2013-10-24 at 21:26 +0300, Anssi Hannula wrote:
24.10.2013 21:10, Anssi Hannula kirjoitti:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Aand that would be http://onse.fi/files/atihdmi6.patch not 5.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
Anssi,
I have tried to patch 3.11.7 and the code in patch_hdmi.c looks too different to be able to able to manually merge the rejected hunks.
What is sound-next? A git branch? Where can I get it?
How independant is the sound subsystem from the rest of the kernel? My guess is that it is not that tightly coupled with the rest and dropping sound-next version of patch_hdmi.c into my 3.11.7 source tree could work or require minimal work. Will upgrade to 3.12 in a couple of day....
08.11.2013 07:08, Olivier Langlois kirjoitti:
On Thu, 2013-10-24 at 21:26 +0300, Anssi Hannula wrote:
24.10.2013 21:10, Anssi Hannula kirjoitti:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Aand that would be http://onse.fi/files/atihdmi6.patch not 5.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
Anssi,
I have tried to patch 3.11.7 and the code in patch_hdmi.c looks too different to be able to able to manually merge the rejected hunks.
What is sound-next? A git branch? Where can I get it?
The sound tree is at: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/
You can use the master branch now, it has been merged there.
How independant is the sound subsystem from the rest of the kernel? My guess is that it is not that tightly coupled with the rest and dropping sound-next version of patch_hdmi.c into my 3.11.7 source tree could work or require minimal work. Will upgrade to 3.12 in a couple of day....
Often you can just copy the sound/pci/hda directory from a newer kernel and then build the modules for the current kernel ("make -C/lib/modules/$(uname -r)/build M=$PWD") with only minimal changes and possibly disabling unused modules in Makefile.
What is sound-next? A git branch? Where can I get it?
The sound tree is at: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/
You can use the master branch now, it has been merged there.
I'm no git expert but I had problem cloning the repository:
lano1106@whippet2 ~/dev $ git clone https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/ Cloning into 'sound'... error: Unable to find 97c4de8fc0a47b99220b1209c7457c7dde05637a under https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git Cannot obtain needed object 97c4de8fc0a47b99220b1209c7457c7dde05637a while processing commit ff8c5075a3b474cd9e422eb7e5a97e48f38a9b08.
but I did cherrypicked successfully hda_codec,hda_jack,hda_eld and patch_hdmi modules from the browser interface of the repo and 3.11.7 did compile fine.
I'll probably be able to report the testing of your patch sometime later this afternoon.
On Fri, 2013-11-08 at 13:17 -0500, Olivier Langlois wrote:
What is sound-next? A git branch? Where can I get it?
The sound tree is at: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/
You can use the master branch now, it has been merged there.
I'm no git expert but I had problem cloning the repository:
lano1106@whippet2 ~/dev $ git clone https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/ Cloning into 'sound'... error: Unable to find 97c4de8fc0a47b99220b1209c7457c7dde05637a under https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git Cannot obtain needed object 97c4de8fc0a47b99220b1209c7457c7dde05637a while processing commit ff8c5075a3b474cd9e422eb7e5a97e48f38a9b08.
but I did cherrypicked successfully hda_codec,hda_jack,hda_eld and patch_hdmi modules from the browser interface of the repo and 3.11.7 did compile fine.
I'll probably be able to report the testing of your patch sometime later this afternoon.
Hi Anssi,
here is initial result of my testing of v3 of your patch.
Either my backporting missed something or a regression has slipped into the newest version but speaker mapping looks slightly broken. I have this:
lano1106@whippet2 ~ $ speaker-test -D hdmi:CARD=HDMI,DEV=0 -c8 -r192000 -F S32_LE
speaker-test 1.0.27.2
Playback device is hdmi:CARD=HDMI,DEV=0 Stream parameters are 192000Hz, S32_LE, 8 channels Using 16 octaves of pink noise Rate set to 192000Hz (requested 192000Hz) Buffer size range from 8 to 131072 Period size range from 4 to 65536 Using max buffer size 131072 Periods = 4 was set period_size = 32768 was set buffer_size = 131072 0 - Front Left 4 - Center 1 - Front Right 7 - Side Right 7 - Side Right 6 - Side Left 6 - Side Left 5 - LFE
With v2, rear channels were there.
Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100300
08.11.2013 23:28, Olivier Langlois kirjoitti:
On Fri, 2013-11-08 at 13:17 -0500, Olivier Langlois wrote:
What is sound-next? A git branch? Where can I get it?
The sound tree is at: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/
You can use the master branch now, it has been merged there.
I'm no git expert but I had problem cloning the repository:
lano1106@whippet2 ~/dev $ git clone https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/ Cloning into 'sound'... error: Unable to find 97c4de8fc0a47b99220b1209c7457c7dde05637a under https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git Cannot obtain needed object 97c4de8fc0a47b99220b1209c7457c7dde05637a while processing commit ff8c5075a3b474cd9e422eb7e5a97e48f38a9b08.
That is just a web URL, in there you can see the checkoutable URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
but I did cherrypicked successfully hda_codec,hda_jack,hda_eld and patch_hdmi modules from the browser interface of the repo and 3.11.7 did compile fine.
You mean you just downloaded the files and put them in-tree, right?
If it built without warnings, it is probably OK...
I'll probably be able to report the testing of your patch sometime later this afternoon.
Hi Anssi,
here is initial result of my testing of v3 of your patch.
Either my backporting missed something or a regression has slipped into the newest version but speaker mapping looks slightly broken. I have this:
lano1106@whippet2 ~ $ speaker-test -D hdmi:CARD=HDMI,DEV=0 -c8 -r192000 -F S32_LE
speaker-test 1.0.27.2
Playback device is hdmi:CARD=HDMI,DEV=0 Stream parameters are 192000Hz, S32_LE, 8 channels Using 16 octaves of pink noise Rate set to 192000Hz (requested 192000Hz) Buffer size range from 8 to 131072 Period size range from 4 to 65536 Using max buffer size 131072 Periods = 4 was set period_size = 32768 was set buffer_size = 131072 0 - Front Left 4 - Center 1 - Front Right 7 - Side Right 7 - Side Right 6 - Side Left 6 - Side Left 5 - LFE
With v2, rear channels were there.
OK, this is pretty weird indeed. Could you apply the attached debugging prints and then provide dmesg?
Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100300
Hi Anssi,
On Sat, 2013-11-09 at 00:03 +0200, Anssi Hannula wrote:
You mean you just downloaded the files and put them in-tree, right?
Right. Here are the files that I have replaced in 3.11.7 tree:
lano1106@whippet2 ~/dev/linux-ck/src/linux-3.11/sound/pci/hda $ ls *.orig hda_codec.c.orig hda_codec.h.orig hda_eld.c.orig hda_jack.c.orig hda_jack.h.orig hda_local.h.orig patch_hdmi.c.orig
If it built without warnings, it is probably OK...
It has built flawlessly.
OK, this is pretty weird indeed. Could you apply the attached debugging prints and then provide dmesg?
Sure, here is the output:
[ 78.384821] ALSA sound/pci/hda/patch_hdmi.c:1167 HDMI hot plug event: Codec=0 Pin=3 Device=0 Inactive=0 Presence_Detect=0 ELD_Valid=1 [ 78.384834] ALSA sound/pci/hda/patch_hdmi.c:1512 HDMI status: Codec=0 Pin=3 Presence_Detect=1 ELD_Valid=1 [ 128.437676] ALSA sound/pci/hda/patch_hdmi.c:678 HDMI: select CA 0x13 for 8-channel allocation: FL/FR LFE FC RL/RR RLC/RRC [ 128.437797] CA XX 19 => 8 [ 128.437799] XX hdmi_map 00 [ 128.437801] XX hdmi_map 11 [ 128.437802] XX hdmi_map 26 [ 128.437804] XX hdmi_map 37 [ 128.437806] XX hdmi_map 43 [ 128.437807] XX hdmi_map 52 [ 128.437809] XX hdmi_map 64 [ 128.437810] XX hdmi_map 75 [ 128.437957] ALSA sound/pci/hda/patch_hdmi.c:3108 atihdmi_pin_hbr_setup: NID=0x3, hbr-ctl=0x1
This is looking good. Maybe this is coming from how the channel mapping is communicated to speaker-test through ALSA API but I don't know much about that.
I'll try to understand as well on my side what is going on.
10.11.2013 07:42, Olivier Langlois kirjoitti:
Hi Anssi,
On Sat, 2013-11-09 at 00:03 +0200, Anssi Hannula wrote:
You mean you just downloaded the files and put them in-tree, right?
Right. Here are the files that I have replaced in 3.11.7 tree:
lano1106@whippet2 ~/dev/linux-ck/src/linux-3.11/sound/pci/hda $ ls *.orig hda_codec.c.orig hda_codec.h.orig hda_eld.c.orig hda_jack.c.orig hda_jack.h.orig hda_local.h.orig patch_hdmi.c.orig
If it built without warnings, it is probably OK...
It has built flawlessly.
OK, this is pretty weird indeed. Could you apply the attached debugging prints and then provide dmesg?
Sure, here is the output:
[ 78.384821] ALSA sound/pci/hda/patch_hdmi.c:1167 HDMI hot plug event: Codec=0 Pin=3 Device=0 Inactive=0 Presence_Detect=0 ELD_Valid=1 [ 78.384834] ALSA sound/pci/hda/patch_hdmi.c:1512 HDMI status: Codec=0 Pin=3 Presence_Detect=1 ELD_Valid=1 [ 128.437676] ALSA sound/pci/hda/patch_hdmi.c:678 HDMI: select CA 0x13 for 8-channel allocation: FL/FR LFE FC RL/RR RLC/RRC [ 128.437797] CA XX 19 => 8 [ 128.437799] XX hdmi_map 00 [ 128.437801] XX hdmi_map 11 [ 128.437802] XX hdmi_map 26 [ 128.437804] XX hdmi_map 37 [ 128.437806] XX hdmi_map 43 [ 128.437807] XX hdmi_map 52 [ 128.437809] XX hdmi_map 64 [ 128.437810] XX hdmi_map 75 [ 128.437957] ALSA sound/pci/hda/patch_hdmi.c:3108 atihdmi_pin_hbr_setup: NID=0x3, hbr-ctl=0x1
This is looking good. Maybe this is coming from how the channel mapping is communicated to speaker-test through ALSA API but I don't know much about that.
I'll try to understand as well on my side what is going on.
Hmm seems I can reproduce this issue just fine on my side now on non-AMD, so I'm going to look into this myself as well. Looks a bit like a speaker-test bug to me (since the printed channel numbers are duplicated, and amixer shows proper chmap), though if that is the case I wonder why I didn't see this before... I'll take a look.
10.11.2013 08:01, Anssi Hannula kirjoitti:
10.11.2013 07:42, Olivier Langlois kirjoitti:
On Sat, 2013-11-09 at 00:03 +0200, Anssi Hannula wrote:
08.11.2013 23:28, Olivier Langlois kirjoitti:
lano1106@whippet2 ~ $ speaker-test -D hdmi:CARD=HDMI,DEV=0 -c8 -r192000 -F S32_LE
speaker-test 1.0.27.2
Playback device is hdmi:CARD=HDMI,DEV=0 Stream parameters are 192000Hz, S32_LE, 8 channels Using 16 octaves of pink noise Rate set to 192000Hz (requested 192000Hz) Buffer size range from 8 to 131072 Period size range from 4 to 65536 Using max buffer size 131072 Periods = 4 was set period_size = 32768 was set buffer_size = 131072 0 - Front Left 4 - Center 1 - Front Right 7 - Side Right 7 - Side Right 6 - Side Left 6 - Side Left 5 - LFE
[...]
OK, speaker-test bug (affecting all generic HDMI codecs).
This is triggered by the fact that the standard CEA/HDMI 8 channel mapping contains RL/RR and RLC/RRC instead of SL/SR and RL/RR. I.e. what one usually considers side speakers is RL/RR and then the rear speakers are RLC/RRC (rear-left-center, rear-right-center).
Speaker-test tries to play back channels in the following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 which are actually "SL/SR" but with a different name (RL/RR).
When it becomes time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does. However, of course the chmap RL/RR corresponds to the HDMI/CEA RL/RR which is traditionally SL/SR. So SL/SR is outputted again.
AFAICS the most straight-forward way to fix this is to check that the chmap actually comprises of the assumed regular channels before trying to apply the predefined playback order, and then fallback to playing channels in-order 0-7 (maybe also provide a predefined ordering for the CEA/HDMI 8ch chmap, though). I can do that later, right now I'm too tired.
BTW, currently speaker-test always uses its own hardcoded channel number=>name mappings for showing the channel name, unless a channel map was manually specified. This is clearly wrong since there may be a device-specific non-standard channelmap.
I can fix that as well, but of course that would mess up the output for HDMI when this is not applied: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
So what to do, can we show wrong channel names on broken kernels or should we wait a bit? I guess that one really should be pushed to -stable in any case...
(There is also the question if we want to change the HDMI channel mapping to appear as traditional side+rear instead of the CEA rear+rearcenter. I don't have a strong preference on this so I'm fine with status quo.)
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
For example, the CEA/HDMI 8ch map is FL,FR,RLC,RRC,FC,LFE,RL,RR. Note that it is otherwise the same as the traditional ALSA channel map, except that the traditional rear speakers are considered rear-center speakers and the traditional side speakers are considered rear speakers.
Speaker-test tries to play back channels in this following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is the time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 (which indeed are the side speakers, or RL/RR in this channel map - so the correct channels are selected).
When it becomes the time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does find them in the chmap positions 6/7.
So the channels 6/7 are tested twice and 2/3 are never tested.
To fix this, define a generic playback order to be used when a channel map is present and assign the speaker numbers (i.e. playback order) in the following order: 1. channels in map found in map_order[] in the map_order[] order, 2. channels in map not found in map_order[] in map order, 3. channels outside the map.
When the channel mapping is specified manually, the specified order is used for playback as before.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi --- speaker-test/speaker-test.c | 86 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 67 insertions(+), 19 deletions(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index d35065f..274007d 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -88,6 +88,8 @@ enum { #define BE_INT(v) (v) #endif
+#define ARRAY_SIZE(x) (int)(sizeof(x)/sizeof(x[0])) + static char *device = "default"; /* playback device */ static snd_pcm_format_t format = SND_PCM_FORMAT_S16; /* sample format */ static unsigned int rate = 48000; /* stream rate */ @@ -156,36 +158,82 @@ static const int channels8[] = { 5, /* LFE */ };
+#ifdef CONFIG_SUPPORT_CHMAP +/* generic version of the above channelsX[] */ +static const int map_order[] = { + SND_CHMAP_FLW, + SND_CHMAP_FL, + SND_CHMAP_TFL, + SND_CHMAP_FLC, + SND_CHMAP_TFLC, + SND_CHMAP_FC, + SND_CHMAP_TFC, + SND_CHMAP_FRC, + SND_CHMAP_TFRC, + SND_CHMAP_FR, + SND_CHMAP_TFR, + SND_CHMAP_FRW, + SND_CHMAP_SR, + SND_CHMAP_TSR, + SND_CHMAP_RR, + SND_CHMAP_TRR, + SND_CHMAP_RRC, + SND_CHMAP_RC, + SND_CHMAP_TRC, + SND_CHMAP_RLC, + SND_CHMAP_RL, + SND_CHMAP_TRL, + SND_CHMAP_SL, + SND_CHMAP_TSL, + SND_CHMAP_BC, + SND_CHMAP_TC, + SND_CHMAP_LLFE, + SND_CHMAP_LFE, + SND_CHMAP_RLFE, +}; + static int get_mapped_channel(int chn) { -#ifdef CONFIG_SUPPORT_CHMAP - static const int maps[MAX_CHANNELS] = { - SND_CHMAP_FL, - SND_CHMAP_FR, - SND_CHMAP_RL, - SND_CHMAP_RR, - SND_CHMAP_FC, - SND_CHMAP_LFE, - SND_CHMAP_SL, - SND_CHMAP_SR, - }; + int found_count = 0; + int i, j; + + if (chn >= channel_map->channels) + return chn; /* out of map */
- if (channel_map && maps[chn]) { - int i; - for (i = 0; i < channel_map->channels; i++) { - if (channel_map->pos[i] == maps[chn]) - return i; + for (i = 0; i < ARRAY_SIZE(map_order) && found_count <= chn; i++) { + for (j = 0; j < channel_map->channels; j++) { + if (channel_map->pos[j] == map_order[i]) { + found_count++; + break; + } } } -#endif - return chn; + + if (found_count == chn + 1) + return j; + + /* chn is bigger than the amount of present map_order[] channels, find + * the non-map_order[] channels */ + for (j = 0; j < channel_map->channels && found_count <= chn; j++) { + for (i = 0; i < ARRAY_SIZE(map_order); i++) { + if (channel_map->pos[j] == map_order[i]) + break; + } + if (i == ARRAY_SIZE(map_order)) + found_count++; + } + + return j - 1; } +#endif
static int get_speaker_channel(int chn) { #ifdef CONFIG_SUPPORT_CHMAP if (channel_map_set) return chn; + if (channel_map) + return get_mapped_channel(chn); #endif
switch (channels) { @@ -200,7 +248,7 @@ static int get_speaker_channel(int chn) break; }
- return get_mapped_channel(chn); + return chn; }
static const char *get_channel_name(int chn)
Currently speaker-test only uses channel names retrieved by snd_pcm_chmap_long_name() when a channel map has been manually set.
However, the device may provide a default (or fixed) channel map that differs from the traditional ALSA map, in which case wrong channel names are shown.
Fix that by always using the name from the channel map when a channel map is present.
Note that the names retrieved by snd_pcm_chmap_long_name() are not currently localized via gettext.
Also note that Linux kernel HDMI driver reported wrong default channel maps before 56cac413dd6d43af8355f5d1f90a199b540f73fc ("ALSA: hda - hdmi: Fix reported channel map on common default layouts").
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi --- speaker-test/speaker-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index 274007d..82cc3b1 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -254,7 +254,7 @@ static int get_speaker_channel(int chn) static const char *get_channel_name(int chn) { #ifdef CONFIG_SUPPORT_CHMAP - if (channel_map_set && chn < channel_map->channels) { + if (channel_map && chn < channel_map->channels) { const char *name = snd_pcm_chmap_long_name(channel_map->pos[chn]); return name ? name : "Unknown"; }
Currently speaker-test falls back to ALSA default channel names for channels out-of-chmap.
This causes e.g. the 4th channel of $ speaker-test -c4 -Dhdmi -m "FR,FL,FC" to be shown as "Rear Right".
Change the code to show such channels as Unknown instead, similar to when snd_pcm_chmap_long_name() does not know the name.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi --- speaker-test/speaker-test.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index 82cc3b1..8ab5011 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -254,8 +254,10 @@ static int get_speaker_channel(int chn) static const char *get_channel_name(int chn) { #ifdef CONFIG_SUPPORT_CHMAP - if (channel_map && chn < channel_map->channels) { - const char *name = snd_pcm_chmap_long_name(channel_map->pos[chn]); + if (channel_map) { + const char *name = NULL; + if (chn < channel_map->channels) + name = snd_pcm_chmap_long_name(channel_map->pos[chn]); return name ? name : "Unknown"; } #endif
At Sun, 10 Nov 2013 20:29:17 +0200, Anssi Hannula wrote:
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
For example, the CEA/HDMI 8ch map is FL,FR,RLC,RRC,FC,LFE,RL,RR. Note that it is otherwise the same as the traditional ALSA channel map, except that the traditional rear speakers are considered rear-center speakers and the traditional side speakers are considered rear speakers.
Speaker-test tries to play back channels in this following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is the time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 (which indeed are the side speakers, or RL/RR in this channel map - so the correct channels are selected).
When it becomes the time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does find them in the chmap positions 6/7.
So the channels 6/7 are tested twice and 2/3 are never tested.
To fix this, define a generic playback order to be used when a channel map is present and assign the speaker numbers (i.e. playback order) in the following order:
- channels in map found in map_order[] in the map_order[] order,
- channels in map not found in map_order[] in map order,
- channels outside the map.
You are referring to the teaching of Zen, aren't you...? ;)
I prefer something a bit more easier to understand. For example, how about to sort the given channels once using a weight table?
thanks,
Takashi
When the channel mapping is specified manually, the specified order is used for playback as before.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi
speaker-test/speaker-test.c | 86 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 67 insertions(+), 19 deletions(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index d35065f..274007d 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -88,6 +88,8 @@ enum { #define BE_INT(v) (v) #endif
+#define ARRAY_SIZE(x) (int)(sizeof(x)/sizeof(x[0]))
static char *device = "default"; /* playback device */ static snd_pcm_format_t format = SND_PCM_FORMAT_S16; /* sample format */ static unsigned int rate = 48000; /* stream rate */ @@ -156,36 +158,82 @@ static const int channels8[] = { 5, /* LFE */ };
+#ifdef CONFIG_SUPPORT_CHMAP +/* generic version of the above channelsX[] */ +static const int map_order[] = {
- SND_CHMAP_FLW,
- SND_CHMAP_FL,
- SND_CHMAP_TFL,
- SND_CHMAP_FLC,
- SND_CHMAP_TFLC,
- SND_CHMAP_FC,
- SND_CHMAP_TFC,
- SND_CHMAP_FRC,
- SND_CHMAP_TFRC,
- SND_CHMAP_FR,
- SND_CHMAP_TFR,
- SND_CHMAP_FRW,
- SND_CHMAP_SR,
- SND_CHMAP_TSR,
- SND_CHMAP_RR,
- SND_CHMAP_TRR,
- SND_CHMAP_RRC,
- SND_CHMAP_RC,
- SND_CHMAP_TRC,
- SND_CHMAP_RLC,
- SND_CHMAP_RL,
- SND_CHMAP_TRL,
- SND_CHMAP_SL,
- SND_CHMAP_TSL,
- SND_CHMAP_BC,
- SND_CHMAP_TC,
- SND_CHMAP_LLFE,
- SND_CHMAP_LFE,
- SND_CHMAP_RLFE,
+};
static int get_mapped_channel(int chn) { -#ifdef CONFIG_SUPPORT_CHMAP
- static const int maps[MAX_CHANNELS] = {
- SND_CHMAP_FL,
- SND_CHMAP_FR,
- SND_CHMAP_RL,
- SND_CHMAP_RR,
- SND_CHMAP_FC,
- SND_CHMAP_LFE,
- SND_CHMAP_SL,
- SND_CHMAP_SR,
- };
- int found_count = 0;
- int i, j;
- if (chn >= channel_map->channels)
- return chn; /* out of map */
- if (channel_map && maps[chn]) {
- int i;
- for (i = 0; i < channel_map->channels; i++) {
if (channel_map->pos[i] == maps[chn])- return i;
- for (i = 0; i < ARRAY_SIZE(map_order) && found_count <= chn; i++) {
- for (j = 0; j < channel_map->channels; j++) {
if (channel_map->pos[j] == map_order[i]) {found_count++;- break;
}-#endif
- return chn;
- if (found_count == chn + 1)
- return j;
- /* chn is bigger than the amount of present map_order[] channels, find
- the non-map_order[] channels */
- for (j = 0; j < channel_map->channels && found_count <= chn; j++) {
- for (i = 0; i < ARRAY_SIZE(map_order); i++) {
if (channel_map->pos[j] == map_order[i])break;- }
- if (i == ARRAY_SIZE(map_order))
found_count++;- }
- return j - 1;
} +#endif
static int get_speaker_channel(int chn) { #ifdef CONFIG_SUPPORT_CHMAP if (channel_map_set) return chn;
- if (channel_map)
- return get_mapped_channel(chn);
#endif
switch (channels) { @@ -200,7 +248,7 @@ static int get_speaker_channel(int chn) break; }
- return get_mapped_channel(chn);
- return chn;
}
static const char *get_channel_name(int chn)
1.8.1.5
11.11.2013 17:56, Takashi Iwai kirjoitti:
At Sun, 10 Nov 2013 20:29:17 +0200, Anssi Hannula wrote:
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
For example, the CEA/HDMI 8ch map is FL,FR,RLC,RRC,FC,LFE,RL,RR. Note that it is otherwise the same as the traditional ALSA channel map, except that the traditional rear speakers are considered rear-center speakers and the traditional side speakers are considered rear speakers.
Speaker-test tries to play back channels in this following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is the time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 (which indeed are the side speakers, or RL/RR in this channel map - so the correct channels are selected).
When it becomes the time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does find them in the chmap positions 6/7.
So the channels 6/7 are tested twice and 2/3 are never tested.
To fix this, define a generic playback order to be used when a channel map is present and assign the speaker numbers (i.e. playback order) in the following order:
- channels in map found in map_order[] in the map_order[] order,
- channels in map not found in map_order[] in map order,
- channels outside the map.
You are referring to the teaching of Zen, aren't you...? ;)
Heh, I only realized afterwards how confusing that map order stuff sounds :p
I prefer something a bit more easier to understand. For example, how about to sort the given channels once using a weight table?
OK, I'll try something like that.
thanks,
Takashi
When the channel mapping is specified manually, the specified order is used for playback as before.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi
speaker-test/speaker-test.c | 86 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 67 insertions(+), 19 deletions(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index d35065f..274007d 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -88,6 +88,8 @@ enum { #define BE_INT(v) (v) #endif
+#define ARRAY_SIZE(x) (int)(sizeof(x)/sizeof(x[0]))
static char *device = "default"; /* playback device */ static snd_pcm_format_t format = SND_PCM_FORMAT_S16; /* sample format */ static unsigned int rate = 48000; /* stream rate */ @@ -156,36 +158,82 @@ static const int channels8[] = { 5, /* LFE */ };
+#ifdef CONFIG_SUPPORT_CHMAP +/* generic version of the above channelsX[] */ +static const int map_order[] = {
- SND_CHMAP_FLW,
- SND_CHMAP_FL,
- SND_CHMAP_TFL,
- SND_CHMAP_FLC,
- SND_CHMAP_TFLC,
- SND_CHMAP_FC,
- SND_CHMAP_TFC,
- SND_CHMAP_FRC,
- SND_CHMAP_TFRC,
- SND_CHMAP_FR,
- SND_CHMAP_TFR,
- SND_CHMAP_FRW,
- SND_CHMAP_SR,
- SND_CHMAP_TSR,
- SND_CHMAP_RR,
- SND_CHMAP_TRR,
- SND_CHMAP_RRC,
- SND_CHMAP_RC,
- SND_CHMAP_TRC,
- SND_CHMAP_RLC,
- SND_CHMAP_RL,
- SND_CHMAP_TRL,
- SND_CHMAP_SL,
- SND_CHMAP_TSL,
- SND_CHMAP_BC,
- SND_CHMAP_TC,
- SND_CHMAP_LLFE,
- SND_CHMAP_LFE,
- SND_CHMAP_RLFE,
+};
static int get_mapped_channel(int chn) { -#ifdef CONFIG_SUPPORT_CHMAP
- static const int maps[MAX_CHANNELS] = {
- SND_CHMAP_FL,
- SND_CHMAP_FR,
- SND_CHMAP_RL,
- SND_CHMAP_RR,
- SND_CHMAP_FC,
- SND_CHMAP_LFE,
- SND_CHMAP_SL,
- SND_CHMAP_SR,
- };
- int found_count = 0;
- int i, j;
- if (chn >= channel_map->channels)
- return chn; /* out of map */
- if (channel_map && maps[chn]) {
- int i;
- for (i = 0; i < channel_map->channels; i++) {
if (channel_map->pos[i] == maps[chn])- return i;
- for (i = 0; i < ARRAY_SIZE(map_order) && found_count <= chn; i++) {
- for (j = 0; j < channel_map->channels; j++) {
if (channel_map->pos[j] == map_order[i]) {found_count++;- break;
}-#endif
- return chn;
- if (found_count == chn + 1)
- return j;
- /* chn is bigger than the amount of present map_order[] channels, find
- the non-map_order[] channels */
- for (j = 0; j < channel_map->channels && found_count <= chn; j++) {
- for (i = 0; i < ARRAY_SIZE(map_order); i++) {
if (channel_map->pos[j] == map_order[i])break;- }
- if (i == ARRAY_SIZE(map_order))
found_count++;- }
- return j - 1;
} +#endif
static int get_speaker_channel(int chn) { #ifdef CONFIG_SUPPORT_CHMAP if (channel_map_set) return chn;
- if (channel_map)
- return get_mapped_channel(chn);
#endif
switch (channels) { @@ -200,7 +248,7 @@ static int get_speaker_channel(int chn) break; }
- return get_mapped_channel(chn);
- return chn;
}
static const char *get_channel_name(int chn)
1.8.1.5
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
For example, the CEA/HDMI 8ch map is FL,FR,RLC,RRC,FC,LFE,RL,RR. Note that it is otherwise the same as the traditional ALSA channel map, except that the traditional rear speakers are considered rear-center speakers and the traditional side speakers are considered rear speakers.
Speaker-test tries to play back channels in this following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is the time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 (which indeed are the side speakers, or RL/RR in this channel map - so the correct channels are selected).
When it becomes the time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does find them in the chmap positions 6/7.
So the channels 6/7 are tested twice and 2/3 are never tested.
To fix this, define a generic playback order channel_order[] to be used when the channel map is present (but not user-defined) and generate a (speaker/playback number => channel number) mapping with the channels ordered in the following order: 1. regular channels found in channel_order[] in the defined order, 2. channels not found in channel_order[] ordered by channel number. 3. UNKNOWN channels ordered by channel number. 4. NA channels ordered by channel number. For channels outside the channel map just use their channel numbers (so they will be last after all of the above).
For example, if the playback device has a fictional default channel map of FR,FL,UNKNOWN1,FOO,BAR,RR,RL,UNKNOWN2, the playback order will be FL,FR,RR,RL,FOO,BAR,UNKNOWN1,UNKNOWN2(,any_extra_channels).
When the channel mapping is specified manually, the specified order is used for playback as before.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi --- speaker-test/speaker-test.c | 113 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 91 insertions(+), 22 deletions(-)
diff --git a/speaker-test/speaker-test.c b/speaker-test/speaker-test.c index 45e92e5..261f399 100644 --- a/speaker-test/speaker-test.c +++ b/speaker-test/speaker-test.c @@ -88,6 +88,8 @@ enum { #define BE_INT(v) (v) #endif
+#define ARRAY_SIZE(x) (int)(sizeof(x)/sizeof(x[0])) + static char *device = "default"; /* playback device */ static snd_pcm_format_t format = SND_PCM_FORMAT_S16; /* sample format */ static unsigned int rate = 48000; /* stream rate */ @@ -110,6 +112,7 @@ static snd_pcm_t *pcm_handle = NULL; #ifdef CONFIG_SUPPORT_CHMAP static snd_pcm_chmap_t *channel_map; static int channel_map_set; +static unsigned int *ordered_channels; #endif
static const char *const channel_name[MAX_CHANNELS] = { @@ -156,36 +159,94 @@ static const int channels8[] = { 5, /* LFE */ };
-static int get_mapped_channel(int chn) -{ #ifdef CONFIG_SUPPORT_CHMAP - static const int maps[MAX_CHANNELS] = { - SND_CHMAP_FL, - SND_CHMAP_FR, - SND_CHMAP_RL, - SND_CHMAP_RR, - SND_CHMAP_FC, - SND_CHMAP_LFE, - SND_CHMAP_SL, - SND_CHMAP_SR, - }; +/* circular clockwise and bottom-to-top order */ +static const int channel_order[] = { + [SND_CHMAP_FLW] = 10, + [SND_CHMAP_FL] = 20, + [SND_CHMAP_TFL] = 30, + [SND_CHMAP_FLC] = 40, + [SND_CHMAP_TFLC] = 50, + [SND_CHMAP_FC] = 60, + [SND_CHMAP_TFC] = 70, + [SND_CHMAP_FRC] = 80, + [SND_CHMAP_TFRC] = 90, + [SND_CHMAP_FR] = 100, + [SND_CHMAP_TFR] = 110, + [SND_CHMAP_FRW] = 120, + [SND_CHMAP_SR] = 130, + [SND_CHMAP_TSR] = 140, + [SND_CHMAP_RR] = 150, + [SND_CHMAP_TRR] = 160, + [SND_CHMAP_RRC] = 170, + [SND_CHMAP_RC] = 180, + [SND_CHMAP_TRC] = 190, + [SND_CHMAP_RLC] = 200, + [SND_CHMAP_RL] = 210, + [SND_CHMAP_TRL] = 220, + [SND_CHMAP_SL] = 230, + [SND_CHMAP_TSL] = 240, + [SND_CHMAP_BC] = 250, + [SND_CHMAP_TC] = 260, + [SND_CHMAP_LLFE] = 270, + [SND_CHMAP_LFE] = 280, + [SND_CHMAP_RLFE] = 290, + /* not in table = 10000 */ + [SND_CHMAP_UNKNOWN] = 20000, + [SND_CHMAP_NA] = 30000, +};
- if (channel_map && maps[chn]) { - int i; - for (i = 0; i < channel_map->channels; i++) { - if (channel_map->pos[i] == maps[chn]) - return i; - } +static int chpos_cmp(const void *chnum1p, const void *chnum2p) +{ + int chnum1 = *(int *)chnum1p; + int chnum2 = *(int *)chnum2p; + int chpos1 = channel_map->pos[chnum1]; + int chpos2 = channel_map->pos[chnum2]; + int weight1 = 10000; + int weight2 = 10000; + + if (chpos1 < ARRAY_SIZE(channel_order) && channel_order[chpos1]) + weight1 = channel_order[chpos1]; + if (chpos2 < ARRAY_SIZE(channel_order) && channel_order[chpos2]) + weight2 = channel_order[chpos2]; + + if (weight1 == weight2) { + /* order by channel number if both have the same position (e.g. UNKNOWN) + * or if neither is in channel_order[] */ + return chnum1 - chnum2; } -#endif - return chn; + + /* order according to channel_order[] */ + return weight1 - weight2; +} + +static int *order_channels(void) +{ + /* create a (playback order => channel number) table with channels ordered + * according to channel_order[] values */ + int i; + int *ordered_chs; + + ordered_chs = calloc(channel_map->channels, sizeof(*ordered_chs)); + if (!ordered_chs) + return NULL; + + for (i = 0; i < channel_map->channels; i++) + ordered_chs[i] = i; + + qsort(ordered_chs, channel_map->channels, sizeof(*ordered_chs), chpos_cmp); + + return ordered_chs; } +#endif
static int get_speaker_channel(int chn) { #ifdef CONFIG_SUPPORT_CHMAP - if (channel_map_set) + if (channel_map_set || (ordered_channels && chn >= channel_map->channels)) return chn; + if (ordered_channels) + return ordered_channels[chn]; #endif
switch (channels) { @@ -200,7 +261,7 @@ static int get_speaker_channel(int chn) break; }
- return get_mapped_channel(chn); + return chn; }
static const char *get_channel_name(int chn) @@ -613,6 +674,11 @@ static int config_chmap(snd_pcm_t *handle, const char *mapstr) }
channel_map = snd_pcm_get_chmap(handle); + + /* create a channel order table for default layouts */ + if (channel_map) + ordered_channels = order_channels(); + return 0; } #endif @@ -1232,6 +1298,9 @@ int main(int argc, char *argv[]) {
free(frames); +#ifdef CONFIG_SUPPORT_CHMAP + free(ordered_channels); +#endif
return prg_exit(EXIT_SUCCESS); }
At Tue, 12 Nov 2013 00:04:02 +0200, Anssi Hannula wrote:
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
For example, the CEA/HDMI 8ch map is FL,FR,RLC,RRC,FC,LFE,RL,RR. Note that it is otherwise the same as the traditional ALSA channel map, except that the traditional rear speakers are considered rear-center speakers and the traditional side speakers are considered rear speakers.
Speaker-test tries to play back channels in this following order: 0, /* Front Left */ 4, /* Center */ 1, /* Front Right */ 7, /* Side Right */ 3, /* Rear Right */ 2, /* Rear Left */ 6, /* Side Left */ 5, /* LFE */
When it is the time to play back Side Left/Right, speaker-test tries to look for SL/SR in the chmap, but doesn't find it, so it just plays back channels 6/7 (which indeed are the side speakers, or RL/RR in this channel map - so the correct channels are selected).
When it becomes the time to playback Rear Left/Right, speaker-test again tries to find RL/RR in the chmap, and this time it does find them in the chmap positions 6/7.
So the channels 6/7 are tested twice and 2/3 are never tested.
To fix this, define a generic playback order channel_order[] to be used when the channel map is present (but not user-defined) and generate a (speaker/playback number => channel number) mapping with the channels ordered in the following order:
- regular channels found in channel_order[] in the defined order,
- channels not found in channel_order[] ordered by channel number.
- UNKNOWN channels ordered by channel number.
- NA channels ordered by channel number.
For channels outside the channel map just use their channel numbers (so they will be last after all of the above).
For example, if the playback device has a fictional default channel map of FR,FL,UNKNOWN1,FOO,BAR,RR,RL,UNKNOWN2, the playback order will be FL,FR,RR,RL,FOO,BAR,UNKNOWN1,UNKNOWN2(,any_extra_channels).
When the channel mapping is specified manually, the specified order is used for playback as before.
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi
Thanks, applied all three patches now.
Takashi
Takashi Iwai kirjoitti 2013-11-12 10:11:
At Tue, 12 Nov 2013 00:04:02 +0200, Anssi Hannula wrote:
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
[...]
Thanks, applied all three patches now.
OK, will you also be sending this to stable as I suggested a few messages before (otherwise the patch 2 will work badly, as noted in the patch description as well)? https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
-- Anssi Hannula
At Tue, 12 Nov 2013 14:34:22 +0200, Anssi Hannula wrote:
Takashi Iwai kirjoitti 2013-11-12 10:11:
At Tue, 12 Nov 2013 00:04:02 +0200, Anssi Hannula wrote:
The channel selection currently does not work properly when there is a driver-provided non-ALSA-traditional channel map but no manual channel map was explicitely requested with "-m".
[...]
Thanks, applied all three patches now.
OK, will you also be sending this to stable as I suggested a few messages before (otherwise the patch 2 will work badly, as noted in the patch description as well)? https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
It's been merged to Linus tree, so feel free to send a mail to stable ML. You just need to tell Greg the commit IDs to pick up.
Takashi
Anssi,
With your speaker-test patch (v1), I have been able to make sure that I could use the 8 channels with my AMD card.
for the ramp up/down testing. I have the same result than with v2 of your patch.
eld#0.0 file content is identical as well.
DTS-HD and Dolby True-HD are sent correctly and recognized by the receiver by using the files from:
http://phoronix.com/forums/showthread.php?27348-TrueHD-DTS-HD-E-AC3-Over-HDM...
with the command:s
aplay -Dhdmi:CARD=HDMI,DEV=0,AES0=6 -c8 -r192000 -f s16_le thd.spdif aplay -Dhdmi:CARD=HDMI,DEV=0,AES0=6 -c8 -r192000 -f s16_le dts.spdif
Sure, here is the output:
[ 78.384821] ALSA sound/pci/hda/patch_hdmi.c:1167 HDMI hot plug event: Codec=0 Pin=3 Device=0 Inactive=0 Presence_Detect=0 ELD_Valid=1 [ 78.384834] ALSA sound/pci/hda/patch_hdmi.c:1512 HDMI status: Codec=0 Pin=3 Presence_Detect=1 ELD_Valid=1 [ 128.437676] ALSA sound/pci/hda/patch_hdmi.c:678 HDMI: select CA 0x13 for 8-channel allocation: FL/FR LFE FC RL/RR RLC/RRC [ 128.437797] CA XX 19 => 8 [ 128.437799] XX hdmi_map 00 [ 128.437801] XX hdmi_map 11 [ 128.437802] XX hdmi_map 26 [ 128.437804] XX hdmi_map 37 [ 128.437806] XX hdmi_map 43 [ 128.437807] XX hdmi_map 52 [ 128.437809] XX hdmi_map 64 [ 128.437810] XX hdmi_map 75 [ 128.437957] ALSA sound/pci/hda/patch_hdmi.c:3108 atihdmi_pin_hbr_setup: NID=0x3, hbr-ctl=0x1
This is looking good. Maybe this is coming from how the channel mapping is communicated to speaker-test through ALSA API but I don't know much about that.
I'll try to understand as well on my side what is going on.
Hmm seems I can reproduce this issue just fine on my side now on non-AMD, so I'm going to look into this myself as well. Looks a bit like a speaker-test bug to me (since the printed channel numbers are duplicated, and amixer shows proper chmap), though if that is the case I wonder why I didn't see this before... I'll take a look.
12.11.2013 08:35, Olivier Langlois kirjoitti:
Anssi,
With your speaker-test patch (v1), I have been able to make sure that I could use the 8 channels with my AMD card.
for the ramp up/down testing. I have the same result than with v2 of your patch.
eld#0.0 file content is identical as well.
DTS-HD and Dolby True-HD are sent correctly and recognized by the receiver by using the files from:
http://phoronix.com/forums/showthread.php?27348-TrueHD-DTS-HD-E-AC3-Over-HDM...
with the command:s
aplay -Dhdmi:CARD=HDMI,DEV=0,AES0=6 -c8 -r192000 -f s16_le thd.spdif aplay -Dhdmi:CARD=HDMI,DEV=0,AES0=6 -c8 -r192000 -f s16_le dts.spdif
OK, good.
Thanks a lot for testing :)
Sure, here is the output:
[ 78.384821] ALSA sound/pci/hda/patch_hdmi.c:1167 HDMI hot plug event: Codec=0 Pin=3 Device=0 Inactive=0 Presence_Detect=0 ELD_Valid=1 [ 78.384834] ALSA sound/pci/hda/patch_hdmi.c:1512 HDMI status: Codec=0 Pin=3 Presence_Detect=1 ELD_Valid=1 [ 128.437676] ALSA sound/pci/hda/patch_hdmi.c:678 HDMI: select CA 0x13 for 8-channel allocation: FL/FR LFE FC RL/RR RLC/RRC [ 128.437797] CA XX 19 => 8 [ 128.437799] XX hdmi_map 00 [ 128.437801] XX hdmi_map 11 [ 128.437802] XX hdmi_map 26 [ 128.437804] XX hdmi_map 37 [ 128.437806] XX hdmi_map 43 [ 128.437807] XX hdmi_map 52 [ 128.437809] XX hdmi_map 64 [ 128.437810] XX hdmi_map 75 [ 128.437957] ALSA sound/pci/hda/patch_hdmi.c:3108 atihdmi_pin_hbr_setup: NID=0x3, hbr-ctl=0x1
This is looking good. Maybe this is coming from how the channel mapping is communicated to speaker-test through ALSA API but I don't know much about that.
I'll try to understand as well on my side what is going on.
Hmm seems I can reproduce this issue just fine on my side now on non-AMD, so I'm going to look into this myself as well. Looks a bit like a speaker-test bug to me (since the printed channel numbers are duplicated, and amixer shows proper chmap), though if that is the case I wonder why I didn't see this before... I'll take a look.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Fri, 08 Nov 2013 13:17:02 -0500, Olivier Langlois wrote:
What is sound-next? A git branch? Where can I get it?
The sound tree is at: https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/
You can use the master branch now, it has been merged there.
I'm no git expert but I had problem cloning the repository:
lano1106@whippet2 ~/dev $ git clone https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/ Cloning into 'sound'... error: Unable to find 97c4de8fc0a47b99220b1209c7457c7dde05637a under https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git Cannot obtain needed object 97c4de8fc0a47b99220b1209c7457c7dde05637a while processing commit ff8c5075a3b474cd9e422eb7e5a97e48f38a9b08.
Use git protocol instead of http.
git clone git://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git
Also, if you already have a Linus git tree, you can save lots of download and spaces by linking to it
git clone --reference /somewhere/linux.git \ git://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git
Takashi
At Thu, 24 Oct 2013 21:10:33 +0300, Anssi Hannula wrote:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
I applied all patches now. You can try sound git tree either master or for-next branch.
thanks,
Takashi
Anssi Hannula (5): ALSA: hda - hdmi: Allow HDA patches to customize more operations ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs
sound/pci/hda/hda_eld.c | 151 +++++++++++ sound/pci/hda/hda_local.h | 4 + sound/pci/hda/patch_hdmi.c | 643 +++++++++++++++++++++++++++++++++++++-------- 3 files changed, 689 insertions(+), 109 deletions(-)
-- Anssi Hannula
On Fri, Oct 25, 2013 at 01:04:45AM +0200, Takashi Iwai wrote:
At Thu, 24 Oct 2013 21:10:33 +0300, Anssi Hannula wrote:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
I applied all patches now. You can try sound git tree either master or for-next branch.
Takashi,
with today's Linus' master and your master branch merged in I get: ERROR: "gen_pool_free" [sound/core/snd-page-alloc.ko] undefined!
my .config had CONFIG_HAS_DMA=y but no CONFIG_GENERIC_ALLOCATOR, is there a select missing?
Anssi,
I gave this a quick test, and it works on my 6850! Nice work! The HDMI output is connected to a Onkyo receiver from the future ;) : EDID for output HDMI-0 Manufacturer: ONK Model: 1 Serial#: 16777216 Year: 2245 Week: 255 EDID Version: 1.3 EDID (in hex): 00ffffffffffff003dcb010000000001 ffff0103800000780a0dc9a057479827 12484c00000001010101010101010101 010101010101011d8018711c1620582c 2500c48e2100009e011d007251d01e20 6e285500c48e2100001e000000fc0054 582d53523637342020202020000000fd 00313d0f2e08000a202020202020019b 02032f724f8504030f0e07069413121e 1d1615012f097f070f1f071707503707 503f07c0834f000066030c00ffff808c 0ad08a20e02d10103e9600c48e210000 18011d80d0721c1620102c2580c48e21 00009e011d00bc52d01e20b8285540c4 8e2100001e8c0ad090204031200c4055 00c48e210000180000000000000000a8
No DTS-HD/TrueHD support, but all 5.1 channels are working correctly.
cat /proc/asound/card0/codec#0 Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100200 No Modem Function Group found Default PCM: rates [0x70]: 32000 44100 48000 bits [0x2]: 16 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 Power: setting=D0, actual=D0 GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled GenLevel Digital category: 0x2 IEC Coding Type: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="ELD", index=0, device=3 Pincap 0x00000094: OUT Detect HDMI Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Connection: 1 0x02
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
Regards, Andre
At Fri, 25 Oct 2013 18:54:52 +0200, Andre Heider wrote:
On Fri, Oct 25, 2013 at 01:04:45AM +0200, Takashi Iwai wrote:
At Thu, 24 Oct 2013 21:10:33 +0300, Anssi Hannula wrote:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
I applied all patches now. You can try sound git tree either master or for-next branch.
Takashi,
with today's Linus' master and your master branch merged in I get: ERROR: "gen_pool_free" [sound/core/snd-page-alloc.ko] undefined!
my .config had CONFIG_HAS_DMA=y but no CONFIG_GENERIC_ALLOCATOR, is there a select missing?
This should have been already fixed. Let me know if the problem still happens with the latest tree.
thanks,
Takashi
25.10.2013 19:54, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 01:04:45AM +0200, Takashi Iwai wrote:
At Thu, 24 Oct 2013 21:10:33 +0300, Anssi Hannula wrote:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
I applied all patches now. You can try sound git tree either master or for-next branch.
[...]
Anssi,
I gave this a quick test, and it works on my 6850! Nice work! The HDMI output is connected to a Onkyo receiver from the future ;) : EDID for output HDMI-0 Manufacturer: ONK Model: 1 Serial#: 16777216 Year: 2245 Week: 255 EDID Version: 1.3 EDID (in hex):
[...]
No DTS-HD/TrueHD support, but all 5.1 channels are working correctly.
Good to hear :)
[...]
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
I'm away from that box now, but will give that a try next week.
Regards, Andre
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Regards, Andre
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Thanks.
On Mon, Oct 28, 2013 at 08:25:22PM +0200, Anssi Hannula wrote:
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Blergh, guess that's my fault for not just using sound/master.
But that looks better:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 4 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24 sad1_coding_type [0x2] AC-3 sad1_channels 8 sad1_rates [0xe0] 32000 44100 48000 sad1_max_bitrate 640000 sad2_coding_type [0x6] AAC-LC sad2_channels 8 sad2_rates [0xe0] 32000 44100 48000 sad2_max_bitrate 640000 sad3_coding_type [0x7] DTS sad3_channels 8 sad3_rates [0xe0] 32000 44100 48000 sad3_max_bitrate 1536000
Thanks, Andre
28.10.2013 20:35, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:25:22PM +0200, Anssi Hannula wrote:
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote:
25.10.2013 19:54, Andre Heider kirjoitti: > cat /proc/asound/card0/eld#0.0 > monitor_present 1 > eld_valid 0
However, this should have eld_valid=1 and contain more info. To get a hint on whether it is a bug in audio or video driver, could you give a log with CONFIG_SND_DEBUG ?
AFAICS the sound git master tree should have the necessary support in the radeon video driver to allow the audio driver to generate a valid ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Blergh, guess that's my fault for not just using sound/master.
But that looks better:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 4 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
Thanks.
Hmm, seems we have bug in the radeon driver, we are missing the 8-channel PCM SAD here.
Can you try the attached patch?
sad1_coding_type [0x2] AC-3 sad1_channels 8 sad1_rates [0xe0] 32000 44100 48000 sad1_max_bitrate 640000 sad2_coding_type [0x6] AAC-LC sad2_channels 8 sad2_rates [0xe0] 32000 44100 48000 sad2_max_bitrate 640000 sad3_coding_type [0x7] DTS sad3_channels 8 sad3_rates [0xe0] 32000 44100 48000 sad3_max_bitrate 1536000
On Mon, Oct 28, 2013 at 10:35:56PM +0200, Anssi Hannula wrote:
28.10.2013 20:35, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:25:22PM +0200, Anssi Hannula wrote:
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti:
On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote: > 25.10.2013 19:54, Andre Heider kirjoitti: >> cat /proc/asound/card0/eld#0.0 >> monitor_present 1 >> eld_valid 0 > > However, this should have eld_valid=1 and contain more info. To get a > hint on whether it is a bug in audio or video driver, could you give a > log with CONFIG_SND_DEBUG ? > > AFAICS the sound git master tree should have the necessary support in > the radeon video driver to allow the audio driver to generate a valid > ELD with your card.
With CONFIG_SND_DEBUG=y I get a bunch of "HDMI ATI/AMD: no speaker allocation for ELD" but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Blergh, guess that's my fault for not just using sound/master.
But that looks better:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 4 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
Thanks.
Hmm, seems we have bug in the radeon driver, we are missing the 8-channel PCM SAD here.
Can you try the attached patch?
Sure, with that patch I get:
monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 5 sad0_coding_type [0x1] LPCM sad0_channels 8 sad0_rates [0x6e0] 32000 44100 48000 88200 96000 sad0_bits [0xe0000] 16 20 24 sad1_coding_type [0x1] LPCM sad1_channels 2 sad1_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad1_bits [0xe0000] 16 20 24 sad2_coding_type [0x2] AC-3 sad2_channels 8 sad2_rates [0xe0] 32000 44100 48000 sad2_max_bitrate 640000 sad3_coding_type [0x6] AAC-LC sad3_channels 8 sad3_rates [0xe0] 32000 44100 48000 sad3_max_bitrate 640000 sad4_coding_type [0x7] DTS sad4_channels 8 sad4_rates [0xe0] 32000 44100 48000 sad4_max_bitrate 1536000
Those are supposed to be hardware capabilities, right? Because I'm pretty sure this dated receiver doesn't support AAC bitstreams.
Thanks, Andre
29.10.2013 00:00, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 10:35:56PM +0200, Anssi Hannula wrote:
28.10.2013 20:35, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:25:22PM +0200, Anssi Hannula wrote:
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote:
28.10.2013 19:52, Andre Heider kirjoitti: > On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote: >> 25.10.2013 19:54, Andre Heider kirjoitti: >>> cat /proc/asound/card0/eld#0.0 >>> monitor_present 1 >>> eld_valid 0 >> >> However, this should have eld_valid=1 and contain more info. To get a >> hint on whether it is a bug in audio or video driver, could you give a >> log with CONFIG_SND_DEBUG ? >> >> AFAICS the sound git master tree should have the necessary support in >> the radeon video driver to allow the audio driver to generate a valid >> ELD with your card. > > With CONFIG_SND_DEBUG=y I get a bunch of > "HDMI ATI/AMD: no speaker allocation for ELD" > but afaics that's about it.
Thanks, that is exactly what I was looking for.
Looks like a radeon driver issue - it does not seem to setup the speaker allocation registers properly (so that ALSA could read them from there), and I verified that the EDID you posted has a valid speaker allocation byte 0x4f.
Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Blergh, guess that's my fault for not just using sound/master.
But that looks better:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 4 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
Thanks.
Hmm, seems we have bug in the radeon driver, we are missing the 8-channel PCM SAD here.
Can you try the attached patch?
Sure, with that patch I get:
monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 5 sad0_coding_type [0x1] LPCM sad0_channels 8 sad0_rates [0x6e0] 32000 44100 48000 88200 96000 sad0_bits [0xe0000] 16 20 24 sad1_coding_type [0x1] LPCM sad1_channels 2 sad1_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad1_bits [0xe0000] 16 20 24 sad2_coding_type [0x2] AC-3 sad2_channels 8 sad2_rates [0xe0] 32000 44100 48000 sad2_max_bitrate 640000 sad3_coding_type [0x6] AAC-LC sad3_channels 8 sad3_rates [0xe0] 32000 44100 48000 sad3_max_bitrate 640000 sad4_coding_type [0x7] DTS sad4_channels 8 sad4_rates [0xe0] 32000 44100 48000 sad4_max_bitrate 1536000
OK, looks good, I'll submit the patch to radeon people then.
Those are supposed to be hardware capabilities, right? Because I'm pretty sure this dated receiver doesn't support AAC bitstreams.
Yep. I did manually verify that your EDID really claims AAC support, though. It could be wrong I guess, and the reported max_bitrate is suspiciously the same as for AC-3.
If you want to try AAC bitstreaming, you can download this: http://onse.fi/files/testi.aac.lc.unconfirmed.spdif and play it back using: aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 \ testi.aac.lc.unconfirmed.spdif
(file unconfirmed as I don't have AAC HW)
On Tue, Oct 29, 2013 at 12:42:12AM +0200, Anssi Hannula wrote:
29.10.2013 00:00, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 10:35:56PM +0200, Anssi Hannula wrote:
28.10.2013 20:35, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:25:22PM +0200, Anssi Hannula wrote:
28.10.2013 20:17, Andre Heider kirjoitti:
On Mon, Oct 28, 2013 at 08:12:43PM +0200, Anssi Hannula wrote: > 28.10.2013 19:52, Andre Heider kirjoitti: >> On Fri, Oct 25, 2013 at 08:23:48PM +0300, Anssi Hannula wrote: >>> 25.10.2013 19:54, Andre Heider kirjoitti: >>>> cat /proc/asound/card0/eld#0.0 >>>> monitor_present 1 >>>> eld_valid 0 >>> >>> However, this should have eld_valid=1 and contain more info. To get a >>> hint on whether it is a bug in audio or video driver, could you give a >>> log with CONFIG_SND_DEBUG ? >>> >>> AFAICS the sound git master tree should have the necessary support in >>> the radeon video driver to allow the audio driver to generate a valid >>> ELD with your card. >> >> With CONFIG_SND_DEBUG=y I get a bunch of >> "HDMI ATI/AMD: no speaker allocation for ELD" >> but afaics that's about it. > > Thanks, that is exactly what I was looking for. > > Looks like a radeon driver issue - it does not seem to setup the speaker > allocation registers properly (so that ALSA could read them from there), > and I verified that the EDID you posted has a valid speaker allocation > byte 0x4f. > > Just to recheck - you are running sound git master, or something else?
This is from 3.12-rc7 with today's sound/master (3fbdaf9b) merged on top.
Ah, OK, that certainly explains it. 3.12-x has this one: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drive...
Could you revert that for testing, just to see if you get proper ELD info then?
Blergh, guess that's my fault for not just using sound/master.
But that looks better:
cat /proc/asound/card0/eld#0.0 monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 4 sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
Thanks.
Hmm, seems we have bug in the radeon driver, we are missing the 8-channel PCM SAD here.
Can you try the attached patch?
Sure, with that patch I get:
monitor_present 1 eld_valid 1 monitor_name connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 5 sad0_coding_type [0x1] LPCM sad0_channels 8 sad0_rates [0x6e0] 32000 44100 48000 88200 96000 sad0_bits [0xe0000] 16 20 24 sad1_coding_type [0x1] LPCM sad1_channels 2 sad1_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad1_bits [0xe0000] 16 20 24 sad2_coding_type [0x2] AC-3 sad2_channels 8 sad2_rates [0xe0] 32000 44100 48000 sad2_max_bitrate 640000 sad3_coding_type [0x6] AAC-LC sad3_channels 8 sad3_rates [0xe0] 32000 44100 48000 sad3_max_bitrate 640000 sad4_coding_type [0x7] DTS sad4_channels 8 sad4_rates [0xe0] 32000 44100 48000 sad4_max_bitrate 1536000
OK, looks good, I'll submit the patch to radeon people then.
Those are supposed to be hardware capabilities, right? Because I'm pretty sure this dated receiver doesn't support AAC bitstreams.
Yep. I did manually verify that your EDID really claims AAC support, though. It could be wrong I guess, and the reported max_bitrate is suspiciously the same as for AC-3.
If you want to try AAC bitstreaming, you can download this: http://onse.fi/files/testi.aac.lc.unconfirmed.spdif and play it back using: aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 \ testi.aac.lc.unconfirmed.spdif
(file unconfirmed as I don't have AAC HW)
That looks like its playing something, but there's no sound at all. The receiver claims there's a Dolby Digital stream active while that aplay command is running... so yeah, looks like the EDID is lying. (Same with another raw AAC LE file I just googled).
But on the good side, multichannel AC3 and DTS passthrough is working flawlessly with XBMC ;)
Thanks again, Andre
Yep. I did manually verify that your EDID really claims AAC support, though. It could be wrong I guess, and the reported max_bitrate is suspiciously the same as for AC-3.
If you want to try AAC bitstreaming, you can download this: http://onse.fi/files/testi.aac.lc.unconfirmed.spdif and play it back using: aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 \ testi.aac.lc.unconfirmed.spdif
(file unconfirmed as I don't have AAC HW)
That looks like its playing something, but there's no sound at all. The receiver claims there's a Dolby Digital stream active while that aplay command is running... so yeah, looks like the EDID is lying. (Same with another raw AAC LE file I just googled).
But on the good side, multichannel AC3 and DTS passthrough is working flawlessly with XBMC ;)
Thanks again, Andre
Just throwing an idea like this. There is a small voice telling me that maybe HDMI receiver supporting AAC expect it wrapped inside ADTS packets rather than just raw AAC stream.
Also note that ffmpeg report formatting problem:
lano1106@hpmini ~ $ ffprobe testi.aac.lc.unconfirmed.spdif ffprobe version 2.1 Copyright (c) 2007-2013 the FFmpeg developers built on Oct 29 2013 15:37:36 with gcc 4.8.2 (GCC) configuration: --prefix=/usr --disable-debug --disable-static --enable-avresample --enable-dxva2 --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-pic --enable-postproc --enable-runtime-cpudetect --enable-shared --enable-swresample --disable-vdpau --disable-vaapi --arch=native --cpu=native --enable-version3 --enable-x11grab libavutil 52. 48.100 / 52. 48.100 libavcodec 55. 39.100 / 55. 39.100 libavformat 55. 19.104 / 55. 19.104 libavdevice 55. 5.100 / 55. 5.100 libavfilter 3. 90.100 / 3. 90.100 libavresample 1. 1. 0 / 1. 1. 0 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 [spdif @ 0x8afc6b0] Invalid AAC packet in IEC 61937 testi.aac.lc.unconfirmed.spdif: Invalid data found when processing input
________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
29.10.2013 21:52, LANGLOIS Olivier PIS -EXT kirjoitti:
Yep. I did manually verify that your EDID really claims AAC support, though. It could be wrong I guess, and the reported max_bitrate is suspiciously the same as for AC-3.
If you want to try AAC bitstreaming, you can download this: http://onse.fi/files/testi.aac.lc.unconfirmed.spdif and play it back using: aplay -Dhdmi:CARD=Generic,DEV=0,AES0=6 -r44100 -f s16_le -c2 \ testi.aac.lc.unconfirmed.spdif
(file unconfirmed as I don't have AAC HW)
That looks like its playing something, but there's no sound at all. The receiver claims there's a Dolby Digital stream active while that aplay command is running... so yeah, looks like the EDID is lying. (Same with another raw AAC LE file I just googled).
Note that compressed audio (except some cases of DTS) requires IEC-61937 encapsulation before output (this can be done e.g. with ffmpeg, "-f spdif"). Not sure if the other file you got was like that, maybe.
But yes, looks like the receiver lies in EDID.
But on the good side, multichannel AC3 and DTS passthrough is working flawlessly with XBMC ;)
Thanks again, Andre
Just throwing an idea like this. There is a small voice telling me that maybe HDMI receiver supporting AAC expect it wrapped inside ADTS packets rather than just raw AAC stream.
Yep, and my sample file is ADTS :)
Also note that ffmpeg report formatting problem:
lano1106@hpmini ~ $ ffprobe testi.aac.lc.unconfirmed.spdif ffprobe version 2.1 Copyright (c) 2007-2013 the FFmpeg developers built on Oct 29 2013 15:37:36 with gcc 4.8.2 (GCC) configuration: --prefix=/usr --disable-debug --disable-static --enable-avresample --enable-dxva2 --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-pic --enable-postproc --enable-runtime-cpudetect --enable-shared --enable-swresample --disable-vdpau --disable-vaapi --arch=native --cpu=native --enable-version3 --enable-x11grab libavutil 52. 48.100 / 52. 48.100 libavcodec 55. 39.100 / 55. 39.100 libavformat 55. 19.104 / 55. 19.104 libavdevice 55. 5.100 / 55. 5.100 libavfilter 3. 90.100 / 3. 90.100 libavresample 1. 1. 0 / 1. 1. 0 libswscale 2. 5.101 / 2. 5.101 libswresample 0. 17.104 / 0. 17.104 libpostproc 52. 3.100 / 52. 3.100 [spdif @ 0x8afc6b0] Invalid AAC packet in IEC 61937 testi.aac.lc.unconfirmed.spdif: Invalid data found when processing input
FFmpeg bug. Patch attached (and sent to ffmpeg-devel@).
The current code writing SADs to the audio registers seems to assume that there is at most a single SAD per audio format.
However, that is not the case. Especially for PCM it is somewhat common for sinks to have two SADs, one for 8-channel and one for 2-channel audio, which may have different supported sample rates (i.e. the sink supports stereo audio at higher sample rates than multichannel audio).
Because of this, only the 2-channel SAD may be used if it appears before the 8-channel SAD. Unless other SADs require otherwise, this may cause the ALSA HDA driver to allow stereo playback only.
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Technically there are even more cases to handle (multiple non-PCM SADs of the same type, more than two PCM SADs with varying channel counts, etc), but those have not actually been encountered in the field and handling them would be non-trivial.
Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo support and 96kHz 8-channel support (and other 8-channel compressed formats): 00ffffffffffff003dcb010000000001 ffff0103800000780a0dc9a057479827 12484c00000001010101010101010101 010101010101011d8018711c1620582c 2500c48e2100009e011d007251d01e20 6e285500c48e2100001e000000fc0054 582d53523637342020202020000000fd 00313d0f2e08000a202020202020019b 02032f724f8504030f0e07069413121e 1d1615012f097f070f1f071707503707 503f07c0834f000066030c00ffff808c 0ad08a20e02d10103e9600c48e210000 18011d80d0721c1620102c2580c48e21 00009e011d00bc52d01e20b8285540c4 8e2100001e8c0ad090204031200c4055 00c48e210000180000000000000000a8
Signed-off-by: Anssi Hannula anssi.hannula@iki.fi Tested-by: Andre Heider a.heider@gmail.com Cc: Rafał Miłecki zajec5@gmail.com --- drivers/gpu/drm/radeon/dce6_afmt.c | 20 +++++++++++++++----- drivers/gpu/drm/radeon/evergreen_hdmi.c | 20 +++++++++++++++----- drivers/gpu/drm/radeon/r600_hdmi.c | 20 +++++++++++++++----- 3 files changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c b/drivers/gpu/drm/radeon/dce6_afmt.c index 85a69d2..0a0fcee 100644 --- a/drivers/gpu/drm/radeon/dce6_afmt.c +++ b/drivers/gpu/drm/radeon/dce6_afmt.c @@ -198,20 +198,30 @@ void dce6_afmt_write_sad_regs(struct drm_encoder *encoder)
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) { u32 value = 0; + u8 stereo_freqs = 0; + int max_channels = -1; int j;
for (j = 0; j < sad_count; j++) { struct cea_sad *sad = &sads[j];
if (sad->format == eld_reg_to_type[i][1]) { - value = MAX_CHANNELS(sad->channels) | - DESCRIPTOR_BYTE_2(sad->byte2) | - SUPPORTED_FREQUENCIES(sad->freq); + if (sad->channels > max_channels) { + value = MAX_CHANNELS(sad->channels) | + DESCRIPTOR_BYTE_2(sad->byte2) | + SUPPORTED_FREQUENCIES(sad->freq); + max_channels = sad->channels; + } + if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM) - value |= SUPPORTED_FREQUENCIES_STEREO(sad->freq); - break; + stereo_freqs |= sad->freq; + else + break; } } + + value |= SUPPORTED_FREQUENCIES_STEREO(stereo_freqs); + WREG32_ENDPOINT(offset, eld_reg_to_type[i][0], value); }
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index f71ce39..2a4837d 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -139,20 +139,30 @@ static void evergreen_hdmi_write_sad_regs(struct drm_encoder *encoder)
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) { u32 value = 0; + u8 stereo_freqs = 0; + int max_channels = -1; int j;
for (j = 0; j < sad_count; j++) { struct cea_sad *sad = &sads[j];
if (sad->format == eld_reg_to_type[i][1]) { - value = MAX_CHANNELS(sad->channels) | - DESCRIPTOR_BYTE_2(sad->byte2) | - SUPPORTED_FREQUENCIES(sad->freq); + if (sad->channels > max_channels) { + value = MAX_CHANNELS(sad->channels) | + DESCRIPTOR_BYTE_2(sad->byte2) | + SUPPORTED_FREQUENCIES(sad->freq); + max_channels = sad->channels; + } + if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM) - value |= SUPPORTED_FREQUENCIES_STEREO(sad->freq); - break; + stereo_freqs |= sad->freq; + else + break; } } + + value |= SUPPORTED_FREQUENCIES_STEREO(stereo_freqs); + WREG32(eld_reg_to_type[i][0], value); }
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index f443010..da5cfa4 100644 --- a/drivers/gpu/drm/radeon/r600_hdmi.c +++ b/drivers/gpu/drm/radeon/r600_hdmi.c @@ -364,20 +364,30 @@ static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder)
for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) { u32 value = 0; + u8 stereo_freqs = 0; + int max_channels = -1; int j;
for (j = 0; j < sad_count; j++) { struct cea_sad *sad = &sads[j];
if (sad->format == eld_reg_to_type[i][1]) { - value = MAX_CHANNELS(sad->channels) | - DESCRIPTOR_BYTE_2(sad->byte2) | - SUPPORTED_FREQUENCIES(sad->freq); + if (sad->channels > max_channels) { + value = MAX_CHANNELS(sad->channels) | + DESCRIPTOR_BYTE_2(sad->byte2) | + SUPPORTED_FREQUENCIES(sad->freq); + max_channels = sad->channels; + } + if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM) - value |= SUPPORTED_FREQUENCIES_STEREO(sad->freq); - break; + stereo_freqs |= sad->freq; + else + break; } } + + value |= SUPPORTED_FREQUENCIES_STEREO(stereo_freqs); + WREG32(eld_reg_to_type[i][0], value); }
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
Because of this, only the 2-channel SAD may be used if it appears before the 8-channel SAD. Unless other SADs require otherwise, this may cause the ALSA HDA driver to allow stereo playback only.
I can confirm that the problem exists. My SADs (Onkyo TX-SR605): Format: 1 (PCM) Channels:1 Freq:0x7F (32-192) B2:0x07 (16-24b) Format: 1 (PCM) Channels:7 Freq:0x7F (32-192) B2:0x07 (16-24b) Format: 2 (AC3) Channels:7 Freq:0x07 (32-48) B2:0x50 (640?) Format: 7 (DTS) Channels:7 Freq:0x06 (44-48) B2:0xC0 (1536?) Format: 10 (EAC3) Channels:7 Freq:0x06 (44-48) B2:0x00 Format: 11 (DTS_HD) Channels:7 Freq:0x7E (44-192) B2:0x01 Format: 12 (MLP) Channels:7 Freq:0x1E (44-96) B2:0x00
Unfortunately I get only 1 emulated SAD entry for PCM (/proc/asound/card1/eld#0.0): sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
So I can not play 8 channel LPCM "legally" (without forcing player to do so).
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Does it mean that now instead of 2 real SADs: 1) 192kHz support for 2 channels 2) 96kHz support for 8 channels you will only get: 1) 192kHz support for 8 channels ? Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? That doesn't sound good, but on the other hand I can't propose anything better :| Out of curiosity, what does fglrx set in the verbs?
Technically there are even more cases to handle (multiple non-PCM SADs of the same type, more than two PCM SADs with varying channel counts, etc), but those have not actually been encountered in the field and handling them would be non-trivial.
Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo support and 96kHz 8-channel support (and other 8-channel compressed formats):
2013/11/1 Rafał Miłecki zajec5@gmail.com:
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Does it mean that now instead of 2 real SADs:
- 192kHz support for 2 channels
- 96kHz support for 8 channels
you will only get:
- 192kHz support for 8 channels
? Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? That doesn't sound good, but on the other hand I can't propose anything better :|
Ahh, wait. I just noticed you're using SUPPORTED_FREQUENCIES and (different one) SUPPORTED_FREQUENCIES_STEREO there. Sorry I missed that earlier.
Yeah, just code makes much more sense, I just think the logic in setting that frequency may be a bit bad... Let me think about this clearly tomorrow and I'll let you know :)
01.11.2013 01:38, Rafał Miłecki kirjoitti:
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
Because of this, only the 2-channel SAD may be used if it appears before the 8-channel SAD. Unless other SADs require otherwise, this may cause the ALSA HDA driver to allow stereo playback only.
I can confirm that the problem exists. My SADs (Onkyo TX-SR605): Format: 1 (PCM) Channels:1 Freq:0x7F (32-192) B2:0x07 (16-24b) Format: 1 (PCM) Channels:7 Freq:0x7F (32-192) B2:0x07 (16-24b) Format: 2 (AC3) Channels:7 Freq:0x07 (32-48) B2:0x50 (640?) Format: 7 (DTS) Channels:7 Freq:0x06 (44-48) B2:0xC0 (1536?) Format: 10 (EAC3) Channels:7 Freq:0x06 (44-48) B2:0x00 Format: 11 (DTS_HD) Channels:7 Freq:0x7E (44-192) B2:0x01 Format: 12 (MLP) Channels:7 Freq:0x1E (44-96) B2:0x00
Unfortunately I get only 1 emulated SAD entry for PCM (/proc/asound/card1/eld#0.0): sad0_coding_type [0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe0000] 16 20 24
So I can not play 8 channel LPCM "legally" (without forcing player to do so).
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Does it mean that now instead of 2 real SADs:
- 192kHz support for 2 channels
- 96kHz support for 8 channels
you will only get:
- 192kHz support for 8 channels
?
No, the SADs will be separated again by the ATI/AMD ELD generator in hda_eld.c (as the 4th byte in the register contains the PCM stereo rate mask).
I.e., assuming a receiver with 96kHz PCM multichannel limitation, with the patch the video-side sets the three standard SAD bytes according to the SAD with the highest number of channels (8ch+96kHz+24b), and the extra byte contains the or'ed rate mask of all PCM SADs (i.e. 192kHz). The audio-side then notices that 96kHz (in SAD) != 192kHz (in extra byte) and generates two SADs, one with 8ch 96kHz and one with 2ch 192kHz.
Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? That doesn't sound good, but on the other hand I can't propose anything better :|
Well, ALSA does not restrict that currently in any case (the ALSA HDMI code currently only takes the maximum channels/rate/etc into account, it doesn't check if the specific combination is allowed by SADs), but that is mostly just because nobody has added such code yet.
Out of curiosity, what does fglrx set in the verbs?
I don't know, though I'd expect it to put the same values that get put there with this patch.
Technically there are even more cases to handle (multiple non-PCM SADs of the same type, more than two PCM SADs with varying channel counts, etc), but those have not actually been encountered in the field and handling them would be non-trivial.
Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo support and 96kHz 8-channel support (and other 8-channel compressed formats):
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Don't you think that we should use SUPPORTED_FREQUENCIES_STEREO for stereo frequencies only?
if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
stereo_freqs |= sad->freq;
I mean making that (... && sad->channels == 1)
02.11.2013 03:01, Rafał Miłecki kirjoitti:
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
Fix the code to pick the PCM SAD with the highest number of channels, while merging the rate masks of PCM SADs with lower amount of channels into the additional stereo rate mask byte.
Don't you think that we should use SUPPORTED_FREQUENCIES_STEREO for stereo frequencies only?
if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM)
stereo_freqs |= sad->freq;I mean making that (... && sad->channels == 1)
SAD with channels=6,freqs=32..96kHz,bits=16..24 implies that those freqs and bps are supported for all channel counts up to 6 (since it is "Max Number of channels"). Therefore the specified rates are supported in stereo mode as well and I believe should be included in the stereo bitmask.
As per AMD HDA Verbs documentation the 4th byte is "Rates supported for stereo". And since those rates _are_ supported by stereo, IMO they should be there.
2013/11/2 Anssi Hannula anssi.hannula@iki.fi:
SAD with channels=6,freqs=32..96kHz,bits=16..24 implies that those freqs and bps are supported for all channel counts up to 6 (since it is "Max Number of channels"). Therefore the specified rates are supported in stereo mode as well and I believe should be included in the stereo bitmask.
As per AMD HDA Verbs documentation the 4th byte is "Rates supported for stereo". And since those rates _are_ supported by stereo, IMO they should be there.
OK, that sounds sane. Thanks for explaining.
Acked-by: Rafał Miłecki zajec5@gmail.com
2013/10/29 Anssi Hannula anssi.hannula@iki.fi:
if (sad->channels > max_channels) {value = MAX_CHANNELS(sad->channels) |DESCRIPTOR_BYTE_2(sad->byte2) |SUPPORTED_FREQUENCIES(sad->freq);max_channels = sad->channels;}
Just for a record. I was wondering if fglrx sets both: SUPPORTED_FREQUENCIES and SUPPORTED_FREQUENCIES_STEREO for receiver with LPCM stereo only. It does: 00005f84 07070701 (117901057) 00005f88 00000000 (0) 00005f8c 00000000 (0) 00005f90 00000000 (0) 00005f94 00000000 (0) 00005f98 00000000 (0) 00005f9c 00000000 (0) 00005fa0 00000000 (0) 00005fa4 00000000 (0) 00005fa8 00000000 (0) 00005fac 00000000 (0) 00005fb0 00000000 (0) 00005fb4 00000000 (0) 00005fb8 00000000 (0)
So with the above code we'll be compatible with fglrx about that. Nice. Just wanted to note that :)
24.10.2013 21:10, Anssi Hannula kirjoitti:
Hi all!
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Changes:
- added customizable callbacks instead of polluting generic code
- fixed wrong codec id in rev3+ check (as previously noted)
- cosmetics
I've only tested this on NVIDIA/Intel, but I'd guess at least Peter should be able to test this on AMD in a few days or so. The earlier revisions were tested to fully work.
The pairwise channel remapping code seems to indeed still work fine per testing on Peter's system.
Combined patch can be found at: http://onse.fi/files/atihdmi5.patch However, this patchset is on top recent sound-next commits so it does not directly apply on older kernels.
Olivier, I hope you will be able to test this at some point as well (same things as last time), even though it will be a bit more work :)
Anssi Hannula (5): ALSA: hda - hdmi: Allow HDA patches to customize more operations ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support ALSA: hda - hdmi: Add ELD emulation for ATI/AMD codecs ALSA: hda - hdmi: Add HBR bitstreaming support for ATI/AMD HDMI codecs ALSA: hda - hdmi: Disable ramp-up/down for non-PCM on AMD codecs
sound/pci/hda/hda_eld.c | 151 +++++++++++ sound/pci/hda/hda_local.h | 4 + sound/pci/hda/patch_hdmi.c | 643 +++++++++++++++++++++++++++++++++++++-------- 3 files changed, 689 insertions(+), 109 deletions(-)
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
speaker-test 1.0.27.2
Playback device is hdmi:CARD=HDMI,DEV=0 Stream parameters are 48000Hz, S16_LE, 6 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 5440 Period size range from 32 to 2720 Using max buffer size 5440 Periods = 4 was set period_size = 1088 was set buffer_size = 5440 0 - Front Left 4 - Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE
I have tried various sample rates. I have the HDMI cable plugged into the secondary output as my speakerless DVI monitor is plugged into the primary but I have also tried the HDMI cable in the primary output by itself. I even bought the "official" HIS HHDMI4071 adapter as the unbranded one that came with my card looked quite different. None of these things have helped. I must admit that I don't fully understand what this ELD stuff is about but I can tell you that it's not looking too good on my system.
/proc/asound/HDMI/eld#0.0: monitor_present 1 eld_valid 0
I'm guessing the codec file may provide some useful information.
/proc/asound/HDMI/codec#0: Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x70]: 32000 44100 48000 bits [0x2]: 16 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 Power: setting=D0, actual=D0 GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 IEC Coding Type: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="ELD", index=0, device=3 Pincap 0x00000094: OUT Detect HDMI Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Connection: 1 0x02
If it rules anything out, I have had the ALSA a52 plugin working but obviously this isn't an ideal solution. Any help would be appreciated and I'll gladly provide more information. I've done some light kernel hacking but I'm no expert.
Thanks, James
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
speaker-test 1.0.27.2
Playback device is hdmi:CARD=HDMI,DEV=0 Stream parameters are 48000Hz, S16_LE, 6 channels WAV file(s) Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 5440 Period size range from 32 to 2720 Using max buffer size 5440 Periods = 4 was set period_size = 1088 was set buffer_size = 5440 0 - Front Left 4 - Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE
I guess it is the same without "-t wav"?
I have tried various sample rates. I have the HDMI cable plugged into the secondary output as my speakerless DVI monitor is plugged into the primary but I have also tried the HDMI cable in the primary output by itself. I even bought the "official" HIS HHDMI4071 adapter as the unbranded one that came with my card looked quite different. None of these things have helped.
Hmm, I'm not sure what the behavior is supposed to be with multiple video outputs when we have only a single audio output (HDA pin)...
What happens if you plug both of your outputs to the A/V receiver, will only one output get audio?
In any case, I'd guess trying the HDMI cable by itself should've ruled issues with that out...
I must admit that I don't fully understand what this ELD stuff is about but I can tell you that it's not looking too good on my system.
/proc/asound/HDMI/eld#0.0: monitor_present 1 eld_valid 0
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
I'm guessing the codec file may provide some useful information.
/proc/asound/HDMI/codec#0: Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x70]: 32000 44100 48000 bits [0x2]: 16 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 Power: setting=D0, actual=D0 GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 IEC Coding Type: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="ELD", index=0, device=3 Pincap 0x00000094: OUT Detect HDMI Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Connection: 1 0x02
If it rules anything out, I have had the ALSA a52 plugin working but obviously this isn't an ideal solution. Any help would be appreciated and I'll gladly provide more information. I've done some light kernel hacking but I'm no expert.
Is there anything interesting in "dmesg"?
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
I guess it is the same without "-t wav"?
Yes.
I have the HDMI cable plugged into the secondary output as my speakerless DVI monitor is plugged into the primary but I have also tried the HDMI cable in the primary output by itself.
Hmm, I'm not sure what the behavior is supposed to be with multiple video outputs when we have only a single audio output (HDA pin)...
What happens if you plug both of your outputs to the A/V receiver, will only one output get audio?
I tried this and as I expected, it sent the same audio to both outputs. Still stereo only though.
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
There seems to be little to go on here. Would it be worth enabling CONFIG_SND_DEBUG_VERBOSE? I gather it's very noisy but maybe that level of detail is needed. Hopefully you have a better idea.
Regards, James
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
I guess it is the same without "-t wav"?
Yes.
I have the HDMI cable plugged into the secondary output as my speakerless DVI monitor is plugged into the primary but I have also tried the HDMI cable in the primary output by itself.
Hmm, I'm not sure what the behavior is supposed to be with multiple video outputs when we have only a single audio output (HDA pin)...
What happens if you plug both of your outputs to the A/V receiver, will only one output get audio?
I tried this and as I expected, it sent the same audio to both outputs. Still stereo only though.
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
There seems to be little to go on here. Would it be worth enabling CONFIG_SND_DEBUG_VERBOSE? I gather it's very noisy but maybe that level of detail is needed. Hopefully you have a better idea.
Yeah, that would be useful.
Also, forgot to mention, but next time please indicate the part of the log where you start the multichannel speaker-test command (e.g. timestamps).
On Sat, 23 Nov 2013 17:45:00 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
There seems to be little to go on here. Would it be worth enabling CONFIG_SND_DEBUG_VERBOSE? I gather it's very noisy but maybe that level of detail is needed. Hopefully you have a better idea.
Yeah, that would be useful.
I have now done that. It was not as noisy as I expected and only added a few more messages. I broke the message size limit last time so I have posted the log to Gist instead. The timings are noted there.
https://gist.github.com/chewi/7628058
Regards, James
24.11.2013 16:57, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 17:45:00 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
Here's another revision of the ATI/AMD multichannel+HBR patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
There seems to be little to go on here. Would it be worth enabling CONFIG_SND_DEBUG_VERBOSE? I gather it's very noisy but maybe that level of detail is needed. Hopefully you have a better idea.
Yeah, that would be useful.
I have now done that. It was not as noisy as I expected and only added a few more messages. I broke the message size limit last time so I have posted the log to Gist instead. The timings are noted there.
Unfortunately everything looks OK.
Do you have any custom configuration in /etc/asound.conf or ~/.asoundrc?
To narrow it down a bit, are you able to test any of the following: - same card on Windows, - same card on fglrx, - same receiver with a different AMD card, - same receiver with an Intel/NVIDIA card?
On Mon, 25 Nov 2013 15:20:23 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
24.11.2013 16:57, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 17:45:00 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti:
Anssi Hannula <anssi.hannula <at> iki.fi> writes:
> Here's another revision of the ATI/AMD multichannel+HBR > patchset.
Hi Anssi. Many thanks for your work on this. I am very keen to test this new code but have so far been unsuccessful. I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and I can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
Unfortunately everything looks OK.
I had a horrible feeling you'd say that.
Do you have any custom configuration in /etc/asound.conf or ~/.asoundrc?
Just the usual PulseAudio overrides. I don't like PA starting automatically so I have that disabled and run speaker-test without it. I think the -D option bypasses it anyway. I have also run speaker-test through PA just to see and get the same result.
To narrow it down a bit, are you able to test any of the following:
- same card on Windows,
- same card on fglrx,
- same receiver with a different AMD card,
- same receiver with an Intel/NVIDIA card?
I banished real Windows installs from my main desktop after a nasty incident some years ago. ;) I might be able to dedicate the card to a QEMU instance but I've never tried that before.
I could easily try fglrx but I thought it didn't support multichannel? Or this new ALSA code fixes that too?
Unfortunately I don't have any other AMD cards handy. I could try my wife's Ivy Bridge based laptop though.
I'll report back soon.
Regards, James
25.11.2013 16:32, James Le Cuirot kirjoitti:
On Mon, 25 Nov 2013 15:20:23 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
24.11.2013 16:57, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 17:45:00 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 03:05, James Le Cuirot kirjoitti: > Anssi Hannula <anssi.hannula <at> iki.fi> writes: > >> Here's another revision of the ATI/AMD multichannel+HBR >> patchset. > > Hi Anssi. Many thanks for your work on this. I am very keen to > test this new code but have so far been unsuccessful. I have a > Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I > am running the sound/for-next kernel (82755ab) with your > "missing PCM SAD" patch applied. > > The new kernel has allowed ALSA to recognise the card as > multichannel and I can issue the following speaker-test command > but I still only hear "Front Left" and "Front Right" and the > Yahama seems to report the signal as stereo. > > # speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
ELD stuff is not necessary for playback, it is mostly for information (and providing the necessary info for ELD is disabled on radeon DRI drivers on some kernels on some GPUs ATM due to some issues).
Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
Unfortunately everything looks OK.
I had a horrible feeling you'd say that.
Do you have any custom configuration in /etc/asound.conf or ~/.asoundrc?
Just the usual PulseAudio overrides. I don't like PA starting automatically so I have that disabled and run speaker-test without it. I think the -D option bypasses it anyway. I have also run speaker-test through PA just to see and get the same result.
OK.
To narrow it down a bit, are you able to test any of the following:
- same card on Windows,
- same card on fglrx,
- same receiver with a different AMD card,
- same receiver with an Intel/NVIDIA card?
I banished real Windows installs from my main desktop after a nasty incident some years ago. ;) I might be able to dedicate the card to a QEMU instance but I've never tried that before.
I could easily try fglrx but I thought it didn't support multichannel? Or this new ALSA code fixes that too?
Yes, it was only the ALSA code that was missing for multichannel, it works with fglrx as well. With fglrx you should also see the ELD info as it is not disabled there.
Unfortunately I don't have any other AMD cards handy. I could try my wife's Ivy Bridge based laptop though.
I'll report back soon.
On Mon, 25 Nov 2013 16:56:55 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
25.11.2013 16:32, James Le Cuirot kirjoitti:
On Mon, 25 Nov 2013 15:20:23 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
24.11.2013 16:57, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 17:45:00 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
23.11.2013 17:40, James Le Cuirot kirjoitti:
On Sat, 23 Nov 2013 03:29:28 +0200 Anssi Hannula anssi.hannula@iki.fi wrote:
> 23.11.2013 03:05, James Le Cuirot kirjoitti: >> Anssi Hannula <anssi.hannula <at> iki.fi> writes: >> >>> Here's another revision of the ATI/AMD multichannel+HBR >>> patchset. >> >> Hi Anssi. Many thanks for your work on this. I am very keen to >> test this new code but have so far been unsuccessful. I have a >> Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. >> I am running the sound/for-next kernel (82755ab) with your >> "missing PCM SAD" patch applied. >> >> The new kernel has allowed ALSA to recognise the card as >> multichannel and I can issue the following speaker-test >> command but I still only hear "Front Left" and "Front Right" >> and the Yahama seems to report the signal as stereo. >> >> # speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
> ELD stuff is not necessary for playback, it is mostly for > information (and providing the necessary info for ELD is > disabled on radeon DRI drivers on some kernels on some GPUs > ATM due to some issues). > > Is there anything interesting in "dmesg"?
I have attached my dmesg. I enabled ALSA debug and verbose printk but disabled the on-board HDA audio in the BIOS to make it less confusing, and also to see if it made any difference, which it didn't. The only entry I find noteworthy is about the ELD but you say this isn't required.
Unfortunately everything looks OK.
I had a horrible feeling you'd say that.
Do you have any custom configuration in /etc/asound.conf or ~/.asoundrc?
Just the usual PulseAudio overrides. I don't like PA starting automatically so I have that disabled and run speaker-test without it. I think the -D option bypasses it anyway. I have also run speaker-test through PA just to see and get the same result.
OK.
To narrow it down a bit, are you able to test any of the following:
- same card on Windows,
- same card on fglrx,
- same receiver with a different AMD card,
- same receiver with an Intel/NVIDIA card?
I banished real Windows installs from my main desktop after a nasty incident some years ago. ;) I might be able to dedicate the card to a QEMU instance but I've never tried that before.
I could easily try fglrx but I thought it didn't support multichannel? Or this new ALSA code fixes that too?
Yes, it was only the ALSA code that was missing for multichannel, it works with fglrx as well. With fglrx you should also see the ELD info as it is not disabled there.
Unfortunately I don't have any other AMD cards handy. I could try my wife's Ivy Bridge based laptop though.
I'll report back soon.
Hi Anssi,
Guess it wasn't so "soon" after all. This dropped down my priority list and then my receiver blew up. I ended up getting the newer equivalent model, the RX-V775. Despite that, the problem persists, even on a current sound "master" kernel.
There has been a little change though. I now get an ELD. This shows what I would expect based on my receiver.
https://gist.github.com/chewi/7628058
I note that speaker-test doesn't allow me to specify -c6 anymore, only -c8. Maybe that's because of the ELD. I do have a kernel log but not to hand right now. It only seems to show what appears to be normal output anyway.
I was keen to try fglrx but realised I can't because this card is only supported by the legacy driver and that only works with kernels up to around 3.7.
I did try my wife's Ivy Bridge laptop and that worked straight away with no difficulties using the same HDMI cable so it seems that the receiver isn't to blame.
I wanted to rule my Gentoo system out so I booted with Ubuntu 14.04 on a USB stick and got exactly the same results.
I've tried everything else I can think of like not having my stereo monitor connected at the same time. I would dig in to the code but as you have previously commented, everything *looks* fine, so I don't know where to begin. I may just have to get a newer card but that wasn't an investment I was planning to make just yet. :( Any further suggestions are appreciated.
Regards, James
Hi,
13.05.2014 15:01, James Le Cuirot kirjoitti:
>>> >>> Hi Anssi. Many thanks for your work on this. I am very keen to >>> test this new code but have so far been unsuccessful. I have a >>> Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. >>> I am running the sound/for-next kernel (82755ab) with your >>> "missing PCM SAD" patch applied. >>>
[...]
Guess it wasn't so "soon" after all. This dropped down my priority list and then my receiver blew up. I ended up getting the newer equivalent model, the RX-V775. Despite that, the problem persists, even on a current sound "master" kernel.
There has been a little change though. I now get an ELD. This shows what I would expect based on my receiver.
https://gist.github.com/chewi/7628058
I note that speaker-test doesn't allow me to specify -c6 anymore, only -c8. Maybe that's because of the ELD. I do have a kernel log but not to hand right now. It only seems to show what appears to be normal output anyway.
I was keen to try fglrx but realised I can't because this card is only supported by the legacy driver and that only works with kernels up to around 3.7.
I did try my wife's Ivy Bridge laptop and that worked straight away with no difficulties using the same HDMI cable so it seems that the receiver isn't to blame.
I wanted to rule my Gentoo system out so I booted with Ubuntu 14.04 on a USB stick and got exactly the same results.
I've tried everything else I can think of like not having my stereo monitor connected at the same time. I would dig in to the code but as you have previously commented, everything *looks* fine, so I don't know where to begin. I may just have to get a newer card but that wasn't an investment I was planning to make just yet. :( Any further suggestions are appreciated.
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you - sorry about that).
It is a bug that the driver allows the user to try to playback more than 2 channels on such cards as well, which I have in my TODO list to fix. Thanks for the reminder, though I guess it doesn't help much with your situation.
On Tue, 13 May 2014 15:27:47 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you - sorry about that).
Thank you for the quick reply. I'm not sure whether that's strictly true. Wikipedia (though not always correct, I grant you) states that:
"The RV770 series GPU also supports xvYCC color space output and 7.1 surround sound output (LPCM, AC3, DTS) over HDMI."
http://en.wikipedia.org/wiki/Radeon_HD_4000_Series#Multimedia_features
The HD 4670 has the RV730XT chip. It isn't clear in the above statement whether it is referring to the higher models in the range or the range as a whole, given that the RV770 is the foundation chip. Based on my experiences and what you have heard, it's probably the former. This news piece at AnandTech also seems to back it up.
"All of AMD's Radeon HD graphics cards have shipped with their own audio codec, but the Radeon HD 4800 series of cards finally adds support for 8-channel LPCM output over HDMI."
http://www.anandtech.com/show/2556
Looks like a new card for me then. Thanks for your help.
Regards, James
On Tue, 13 May 2014 17:16:17 +0100 James Le Cuirot chewi@aura-online.co.uk wrote:
On Tue, 13 May 2014 15:27:47 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you - sorry about that).
Thank you for the quick reply. I'm not sure whether that's strictly true. Wikipedia (though not always correct, I grant you) states that:
"The RV770 series GPU also supports xvYCC color space output and 7.1 surround sound output (LPCM, AC3, DTS) over HDMI."
http://en.wikipedia.org/wiki/Radeon_HD_4000_Series#Multimedia_features
The HD 4670 has the RV730XT chip. It isn't clear in the above statement whether it is referring to the higher models in the range or the range as a whole, given that the RV770 is the foundation chip. Based on my experiences and what you have heard, it's probably the former. This news piece at AnandTech also seems to back it up.
"All of AMD's Radeon HD graphics cards have shipped with their own audio codec, but the Radeon HD 4800 series of cards finally adds support for 8-channel LPCM output over HDMI."
http://www.anandtech.com/show/2556
Looks like a new card for me then. Thanks for your help.
Aaaand after all that, I dig out the box for the old card to get ready to sell it and what do I see printed on the front? 7.1 Channel Sound! The box looks almost identical to this one:
http://www.overclockers.ua/video/ati-radeon-hd4670-ddr4/01-ati-radeon-hd4670...
This is very confusing. Any thoughts?
Regards, James
Hi Alex,
14.05.2014 00:10, James Le Cuirot kirjoitti:
On Tue, 13 May 2014 17:16:17 +0100 James Le Cuirot chewi@aura-online.co.uk wrote:
On Tue, 13 May 2014 15:27:47 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you - sorry about that).
Thank you for the quick reply. I'm not sure whether that's strictly true. Wikipedia (though not always correct, I grant you) states that:
"The RV770 series GPU also supports xvYCC color space output and 7.1 surround sound output (LPCM, AC3, DTS) over HDMI."
http://en.wikipedia.org/wiki/Radeon_HD_4000_Series#Multimedia_features
The HD 4670 has the RV730XT chip. It isn't clear in the above statement whether it is referring to the higher models in the range or the range as a whole, given that the RV770 is the foundation chip. Based on my experiences and what you have heard, it's probably the former. This news piece at AnandTech also seems to back it up.
"All of AMD's Radeon HD graphics cards have shipped with their own audio codec, but the Radeon HD 4800 series of cards finally adds support for 8-channel LPCM output over HDMI."
http://www.anandtech.com/show/2556
Looks like a new card for me then. Thanks for your help.
Aaaand after all that, I dig out the box for the old card to get ready to sell it and what do I see printed on the front? 7.1 Channel Sound! The box looks almost identical to this one:
http://www.overclockers.ua/video/ati-radeon-hd4670-ddr4/01-ati-radeon-hd4670...
This is very confusing. Any thoughts?
Alex, you told me in IRC some time ago that pre-DCE4 cards do no support multi-channel PCM. Do you know what is going on above? AFAIU James has HD 4670, which is RV730 and therefore has DCE3.2 only, but seems like it should still have multi-channel support.
Multichannel LPCM support seems to be corroborated by various other sources as well, e.g. http://www.avsforum.com/t/1029603/ati-radeon-hd-4600-4800-series-support-7-1...
It doesn't appear to work, though. Is it possible some of those early cards had some other way of getting multichannel LPCM? Looks like the above forum post directs people to use a "ATI HDMI Audio Device" driver from Realtek for Vista/7... ( http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=24&... )
-----Original Message----- From: Anssi Hannula [mailto:anssi.hannula@iki.fi] Sent: Tuesday, May 13, 2014 5:51 PM To: Deucher, Alexander Cc: James Le Cuirot; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH v3 0/5] ALSA: hda - hdmi: ATI/AMD multi- channel and HBR support
Hi Alex,
14.05.2014 00:10, James Le Cuirot kirjoitti:
On Tue, 13 May 2014 17:16:17 +0100 James Le Cuirot chewi@aura-online.co.uk wrote:
On Tue, 13 May 2014 15:27:47 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you - sorry about that).
Thank you for the quick reply. I'm not sure whether that's strictly true. Wikipedia (though not always correct, I grant you) states that:
"The RV770 series GPU also supports xvYCC color space output and 7.1 surround sound output (LPCM, AC3, DTS) over HDMI."
http://en.wikipedia.org/wiki/Radeon_HD_4000_Series#Multimedia_feature s
The HD 4670 has the RV730XT chip. It isn't clear in the above statement whether it is referring to the higher models in the range or the range as a whole, given that the RV770 is the foundation chip. Based on my experiences and what you have heard, it's probably the former. This news piece at AnandTech also seems to back it up.
"All of AMD's Radeon HD graphics cards have shipped with their own audio codec, but the Radeon HD 4800 series of cards finally adds support for 8-channel LPCM output over HDMI."
http://www.anandtech.com/show/2556
Looks like a new card for me then. Thanks for your help.
Aaaand after all that, I dig out the box for the old card to get ready to sell it and what do I see printed on the front? 7.1 Channel Sound! The box looks almost identical to this one:
http://www.overclockers.ua/video/ati-radeon-hd4670-ddr4/01-ati-
radeon-hd4670-sapphire.jpg
This is very confusing. Any thoughts?
Alex, you told me in IRC some time ago that pre-DCE4 cards do no support multi-channel PCM. Do you know what is going on above? AFAIU James has HD 4670, which is RV730 and therefore has DCE3.2 only, but seems like it should still have multi-channel support.
Multichannel LPCM support seems to be corroborated by various other sources as well, e.g. http://www.avsforum.com/t/1029603/ati-radeon-hd-4600-4800-series- support-7-1-channel-hdmi-audio#user_ATIHDMIDriver
It doesn't appear to work, though. Is it possible some of those early cards had some other way of getting multichannel LPCM?
Does it work with a 3.15 kernel? It looks like DCE3.1 (RV770) and 3.2 (RV7xx) systems may support multichannel LPCM. IIRC, setting the SADs was disabled in older kernels since it seemed to cause problems on some systems, but it's been re-enabled in 3.15.
Alex
Looks like the above forum post directs people to use a "ATI HDMI Audio Device" driver from Realtek for Vista/7... ( http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PN id=24&PFid=24&Level=4&Conn=3&DownTypeID=3&GetDown=false )
-- Anssi Hannula
On Wed, 14 May 2014 13:04:13 +0000 "Deucher, Alexander" Alexander.Deucher@amd.com wrote:
-----Original Message----- From: Anssi Hannula [mailto:anssi.hannula@iki.fi] Sent: Tuesday, May 13, 2014 5:51 PM To: Deucher, Alexander Cc: James Le Cuirot; alsa-devel@alsa-project.org Subject: Re: [alsa-devel] [PATCH v3 0/5] ALSA: hda - hdmi: ATI/AMD multi- channel and HBR support
Hi Alex,
14.05.2014 00:10, James Le Cuirot kirjoitti:
On Tue, 13 May 2014 17:16:17 +0100 James Le Cuirot chewi@aura-online.co.uk wrote:
On Tue, 13 May 2014 15:27:47 +0300 Anssi Hannula anssi.hannula@iki.fi wrote:
Unfortunately I've been told that HD 4xxx cards and older do not support multichannel playback, which I didn't know at the time (and I had forgotten your case, hence I didn't get back to you
- sorry about that).
Thank you for the quick reply. I'm not sure whether that's strictly true. Wikipedia (though not always correct, I grant you) states that:
"The RV770 series GPU also supports xvYCC color space output and 7.1 surround sound output (LPCM, AC3, DTS) over HDMI."
http://en.wikipedia.org/wiki/Radeon_HD_4000_Series#Multimedia_feature s
The HD 4670 has the RV730XT chip. It isn't clear in the above statement whether it is referring to the higher models in the range or the range as a whole, given that the RV770 is the foundation chip. Based on my experiences and what you have heard, it's probably the former. This news piece at AnandTech also seems to back it up.
"All of AMD's Radeon HD graphics cards have shipped with their own audio codec, but the Radeon HD 4800 series of cards finally adds support for 8-channel LPCM output over HDMI."
http://www.anandtech.com/show/2556
Looks like a new card for me then. Thanks for your help.
Aaaand after all that, I dig out the box for the old card to get ready to sell it and what do I see printed on the front? 7.1 Channel Sound! The box looks almost identical to this one:
http://www.overclockers.ua/video/ati-radeon-hd4670-ddr4/01-ati-
radeon-hd4670-sapphire.jpg
This is very confusing. Any thoughts?
Alex, you told me in IRC some time ago that pre-DCE4 cards do no support multi-channel PCM. Do you know what is going on above? AFAIU James has HD 4670, which is RV730 and therefore has DCE3.2 only, but seems like it should still have multi-channel support.
Multichannel LPCM support seems to be corroborated by various other sources as well, e.g. http://www.avsforum.com/t/1029603/ati-radeon-hd-4600-4800-series- support-7-1-channel-hdmi-audio#user_ATIHDMIDriver
It doesn't appear to work, though. Is it possible some of those early cards had some other way of getting multichannel LPCM?
Does it work with a 3.15 kernel? It looks like DCE3.1 (RV770) and 3.2 (RV7xx) systems may support multichannel LPCM. IIRC, setting the SADs was disabled in older kernels since it seemed to cause problems on some systems, but it's been re-enabled in 3.15.
Hi Alex,
If you follow back up this thread, you'll see that I have tried a recent sound "master" kernel (post 3.15-rc5) and I get this ELD.
https://gist.github.com/chewi/7628058
Also note that I am using the so-called "proprietary" DVI/HDMI adapter, the HIS HHDMI4071, which I gather is required.
Regards, James
I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and
I
can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as
stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
Why do you use -c6 when your HDMI codec only support stereo
Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
I'm guessing the codec file may provide some useful information.
/proc/asound/HDMI/codec#0: Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x100100 No Modem Function Group found Default PCM: rates [0x70]: 32000 44100 48000 bits [0x2]: 16 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 Power: setting=D0, actual=D0 GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 IEC Coding Type: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0 Control: name="IEC958 Playback Con Mask", index=0, device=0 Control: name="IEC958 Playback Pro Mask", index=0, device=0 Control: name="IEC958 Playback Default", index=0, device=0 Control: name="IEC958 Playback Switch", index=0, device=0 Control: name="ELD", index=0, device=3 Pincap 0x00000094: OUT Detect HDMI Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=01, enabled=1 Connection: 1 0x02
On Mon, 25 Nov 2013 23:07:09 +0800 Raymond Yau superquad.vortex2@gmail.com wrote:
I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and
I
can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as
stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
Why do you use -c6 when your HDMI codec only support stereo
Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
I was under the impression that this card, and all cards in the Radeon 4000 series, are capable of 7.1 LPCM. Are you suggesting otherwise? Either it really isn't, or this information is being wrongly detected, and that could point to the source of the problem.
I was not aware of the significance of these lines before so thanks for pointing this out. Before I tried the new kernel, ALSA wouldn't let me do 6 channel output at all and PulseAudio detected the card as stereo only. Now ALSA doesn't complain and PA detects it as 5.1 so I figured it should work now. Having said that, I'm not sure why PA doesn't report 7.1 but I only have 5.1 speakers anyway.
Regards, James
25.11.2013 17:07, Raymond Yau kirjoitti:
I have a Radeon 4670 (Sapphire branded) connected to a Yamaha RX-V773. I am running the sound/for-next kernel (82755ab) with your "missing PCM SAD" patch applied.
The new kernel has allowed ALSA to recognise the card as multichannel and
I
can issue the following speaker-test command but I still only hear "Front Left" and "Front Right" and the Yahama seems to report the signal as
stereo.
# speaker-test -Dhdmi:CARD=HDMI,DEV=0 -c6 -t wav
Why do you use -c6 when your HDMI codec only support stereo
Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital Converter: stream=1, channel=0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
All ATI/AMD HDMI codecs report stereo only here, their multichannel support is non-standard (probably predates the HDA spec).
participants (9)
-
Andre Heider -
Anssi Hannula -
Deucher, Alexander -
James Le Cuirot -
LANGLOIS Olivier PIS -EXT -
Olivier Langlois -
Rafał Miłecki -
Raymond Yau -
Takashi Iwai