ELD routines and proc interface

Create hda_eld.c for ELD routines and proc interface.

ELD handling routines can be shared by all HDMI codecs, and they are large enough to make a standalone source file.

Some notes on the code:

- Shall we show an empty file if the ELD content is not valid? Well it's not that simple. There could be partially populated ELD, and there may be malformed ELD provided by buggy drivers/monitors. So I tend to expose ELD as it is.

- hdmi_show_eld() and hdmi_print_eld_info() are somehow duplicated The plan is to shrink hdmi_show_eld()/hdmi_show_short_audio_desc(), and to show a compact message at monitor hotplug and driver initialization time.

- The ELD retrieval routines rely on the Intel HDA interface, others are/could be universal and independent ones.

- The ELD proc interface code could be moved to hda_proc.c if necessary.

- How do we name the proc file?
If there are going to be two HDMI pins per codec, then the current naming scheme (eld#<codec no>) will fail.

sound/pci/hda/patch_intelhdmi.c +0 -0

+int hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid)

+void hdmi_show_eld(struct sink_eld *e)

sound/pci/hda/Makefile +1 -0

@@ -4,6 +4,7 @@ snd-hda-intel-y := hda_intel.o
 # designed to be individual modules
 snd-hda-intel-y += hda_codec.o
 snd-hda-intel-$(CONFIG_PROC_FS) += hda_proc.o
+snd-hda-intel-$(CONFIG_SND_HDA_ELD) += hda_eld.o
 snd-hda-intel-$(CONFIG_SND_HDA_HWDEP) += hda_hwdep.o
 snd-hda-intel-$(CONFIG_SND_HDA_INPUT_BEEP) += hda_beep.o
 snd-hda-intel-$(CONFIG_SND_HDA_GENERIC) += hda_generic.o

sound/pci/hda/hda_local.h +0 -7

@@ -276,15 +276,6 @@ static inline int snd_hda_parse_generic_
 #endif
 
 /*
- * generic proc interface
- */
-#ifdef CONFIG_PROC_FS
-int snd_hda_codec_proc_new(struct hda_codec *codec);
-#else
-static inline int snd_hda_codec_proc_new(struct hda_codec *codec) { return 0; }
-#endif

At Thu, 13 Nov 2008 10:21:53 +0800,

Quoted 2 lines · Wu Fengguang

Create hda_eld.c for ELD routines and proc interface.

Thanks for the patch!

Quoted 9 lines

ELD handling routines can be shared by all HDMI codecs, and they are large enough to make a standalone source file.

Some notes on the code:

- Shall we show an empty file if the ELD content is not valid? Well it's not that simple. There could be partially populated ELD, and there may be malformed ELD provided by buggy drivers/monitors. So I tend to expose ELD as it is.

Fair enough.

Quoted 3 lines

- hdmi_show_eld() and hdmi_print_eld_info() are somehow duplicated The plan is to shrink hdmi_show_eld()/hdmi_show_short_audio_desc(), and to show a compact message at monitor hotplug and driver initialization time.

You can create a common print function to accept the callback, such as,

static void hdmi_print(void (*print)(void *, const char *line), void *data,

			   const char *fmt, ...)
{
	char line[80];
	va_list ap;
	va_start(fp, fmt);
	vsnprintf(line, sizeof(line), fmt, ap);
	va_end(ap);
	print(data, line);
}

static void hdmi_print_eld(void (*print)(void *, const char *), void *data,
struct sink_eld *e)

{
	hdmi_print(print, data, "monitor name\t\t%s\n", e->monitor_name);
	...
}

static void print_proc(void *data, const char *line)

{
	snd_iprintf(data, "%s", line);
}

static void hdmi_print_eld_info(struct snd_info_entry *entry,
struct snd_info_buffer *buffer)

{
	hdmi_print_eld(print_proc, buffer, entry->private_data);
}

static void print_console(void *data, const char *line)

{
	printk(KERN_DEBUG "%s", line);
}

void snd_hdmi_show_eld(struct sink_eld *e)

{
	hdmi_print_eld(print_console, NULL, e);
}

Just an idea, though.

Quoted 4 lines

- The ELD retrieval routines rely on the Intel HDA interface, others are/could be universal and independent ones.

- The ELD proc interface code could be moved to hda_proc.c if necessary.

Quoted 3 lines

- How do we name the proc file?
If there are going to be two HDMI pins per codec, then the current naming scheme (eld#<codec no>) will fail.

In theory, yes, but I don't think this would happen.
If this is needed, the currently existing codec#* proc must be fixed, too. So, we can use eld#codec as the simplest way.

Some review comments below:

Quoted 2 lines

sound/pci/hda/patch_intelhdmi.c +0 -0

...

Quoted 2 lines

sound/pci/hda/patch_intelhdmi.c +0 -0

@@ -880,6 +410,11 @@ static int intel_hdmi_build_controls(str
 

sound/pci/hda/patch_intelhdmi.c static int intel_hdmi_build_controls(str · line 416

Quoted 6 lines

sound/pci/hda/patch_intelhdmi.c +4 -0

 static int intel_hdmi_init(struct hda_codec *codec)
 {
+	struct intel_hdmi_spec *spec = codec->spec;
+	struct sink_eld *eld = &spec->sink;
+
+	snd_hda_eld_proc_new(codec, eld);

The proc creation should be rather in patch_intelhdmi(). The init callback is called also at suspend/resume usually.

sound/pci/hda/patch_intelhdmi.c struct hda_codec_preset snd_hda_preset_i · line 465

Quoted 8 lines

sound/pci/hda/patch_intelhdmi.c +1 -0

 	/* disable audio output as early as possible */
 	hdmi_disable_output(codec);
 

@@ -927,3 +462,4 @@ struct hda_codec_preset snd_hda_preset_i
 	{ .id = 0x10951392, .name = "SiI1392 HDMI",     .patch = patch_intel_hdmi },
 	{} /* terminator */
 };
+

Useless space addition.

sound/pci/hda/hda_eld.c line 204

Quoted 9 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 1 line

+int hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid)

I prefer snd_ prefix for global functions to avoid any potential name crashes.

sound/pci/hda/hda_eld.c line 372

Quoted 2 lines

sound/pci/hda/hda_eld.c new file +2 -0

+int hdmi_get_eld(struct sink_eld *eld,
+		 struct hda_codec *codec, hda_nid_t nid)

Ditto.

Quoted 1 line

+void hdmi_show_eld(struct sink_eld *e)

Ditto.

Quoted 23 lines

sound/pci/hda/Makefile +1 -0

@@ -4,6 +4,7 @@ snd-hda-intel-y := hda_intel.o
 # designed to be individual modules
 snd-hda-intel-y += hda_codec.o
 snd-hda-intel-$(CONFIG_PROC_FS) += hda_proc.o
+snd-hda-intel-$(CONFIG_SND_HDA_ELD) += hda_eld.o
 snd-hda-intel-$(CONFIG_SND_HDA_HWDEP) += hda_hwdep.o
 snd-hda-intel-$(CONFIG_SND_HDA_INPUT_BEEP) += hda_beep.o
 snd-hda-intel-$(CONFIG_SND_HDA_GENERIC) += hda_generic.o

sound/pci/hda/hda_local.h +0 -7

@@ -276,15 +276,6 @@ static inline int snd_hda_parse_generic_
 #endif
 
 /*
- * generic proc interface
- */
-#ifdef CONFIG_PROC_FS
-int snd_hda_codec_proc_new(struct hda_codec *codec);
-#else
-static inline int snd_hda_codec_proc_new(struct hda_codec *codec) { return 0; }
-#endif

...

sound/pci/hda/hda_local.h int snd_hda_check_amp_list_power(struct · line 480

Quoted 6 lines

sound/pci/hda/hda_local.h +6 -0

+/*
+ * generic proc interface
+ */
+#ifdef CONFIG_PROC_FS
+int snd_hda_codec_proc_new(struct hda_codec *codec);
+int snd_hda_eld_proc_new(struct hda_codec *codec, struct sink_eld *eld);

I'd put these two declarations rather separately, since snd_hda_proc_new() has nothing to do with ELD. Keep it in the original place.

Quoted 5 lines

Quoted 4 lines

- How do we name the proc file?
If there are going to be two HDMI pins per codec, then the current naming scheme (eld#<codec no>) will fail.

Quoted 3 lines

In theory, yes, but I don't think this would happen.
If this is needed, the currently existing codec#* proc must be fixed, too. So, we can use eld#codec as the simplest way.

I mean one HDMI codec equipped with two output converters and two HDMI pins. In this case there could be two HDMI sinks mapped to one single codec.

Or it would be trivial to do the rename in the future anyway?

Quoted 11 lines

sound/pci/hda/hda_eld.c line 204

Quoted 8 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Yes, converted to BUILD_BUG_ON() and it compiles OK.

At Fri, 14 Nov 2008 09:34:32 +0800,

Quoted 12 lines · Wu Fengguang

Quoted 8 lines

Quoted 4 lines

- How do we name the proc file?
If there are going to be two HDMI pins per codec, then the current naming scheme (eld#<codec no>) will fail.

In theory, yes, but I don't think this would happen.
If this is needed, the currently existing codec#* proc must be fixed, too. So, we can use eld#codec as the simplest way.

I mean one HDMI codec equipped with two output converters and two HDMI pins. In this case there could be two HDMI sinks mapped to one single codec.

Quoted 1 line

Or it would be trivial to do the rename in the future anyway?

Ah, OK, understood. One easy solution is to name the proc file with either pin of audio-out widget NID.

But I'm not sure whether it's worth. The proc file naming isn't strict, so I'd leave it as is.

Quoted 12 lines

Quoted 11 lines

sound/pci/hda/hda_eld.c line 204

Quoted 8 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 1 line

Yes, converted to BUILD_BUG_ON() and it compiles OK.

The question is whether this really triggers the build error properly. Could you check it, simply by changing the caller of grab_bits() with some invalid values? Then you should get a compile error.

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

sound/pci/hda/hda_eld.c line 204

Quoted 9 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 6 lines

Quoted 1 line

Yes, converted to BUILD_BUG_ON() and it compiles OK.

The question is whether this really triggers the build error properly. Could you check it, simply by changing the caller of grab_bits() with some invalid values? Then you should get a compile error.

BUILD_BUG_ON() won't emit errors! So use BUG_ON()?

At Fri, 14 Nov 2008 15:38:56 +0800,

Quoted 20 lines · Wu Fengguang

Quoted 19 lines

Quoted 13 lines

Quoted 12 lines

sound/pci/hda/hda_eld.c line 204

Quoted 9 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 1 line

Yes, converted to BUILD_BUG_ON() and it compiles OK.

The question is whether this really triggers the build error properly. Could you check it, simply by changing the caller of grab_bits() with some invalid values? Then you should get a compile error.

Quoted 1 line

BUILD_BUG_ON() won't emit errors! So use BUG_ON()?

Try to make grab_bits() a macro and check whether BUILD_BUG_ON() works. I think it won't be too bad to use a macro for such a pretty simple case. If the resultant code looks too ugly, we should switch back to BUG_ON().

The difference is that BUILD_BUG_ON() would add no real code while BUG_ON() is a pure run-time check.

Quoted 22 lines · Takashi Iwai

At Fri, 14 Nov 2008 15:38:56 +0800,

Quoted 20 lines · Wu Fengguang

Quoted 19 lines

Quoted 13 lines

Quoted 12 lines

sound/pci/hda/hda_eld.c

Quoted 9 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 1 line

Yes, converted to BUILD_BUG_ON() and it compiles OK.

The question is whether this really triggers the build error properly. Could you check it, simply by changing the caller of grab_bits() with some invalid values? Then you should get a compile error.

Quoted 6 lines

Quoted 1 line

BUILD_BUG_ON() won't emit errors! So use BUG_ON()?

Try to make grab_bits() a macro and check whether BUILD_BUG_ON() works. I think it won't be too bad to use a macro for such a pretty simple case. If the resultant code looks too ugly, we should switch back to BUG_ON().

OK, I'm fine with a macro.

Quoted 2 lines

The difference is that BUILD_BUG_ON() would add no real code while BUG_ON() is a pure run-time check.

But the code should be optimize away by gcc when the constant expression is false?

At Fri, 14 Nov 2008 15:47:37 +0800,

Quoted 36 lines · Wu Fengguang

Quoted 22 lines · Takashi Iwai

At Fri, 14 Nov 2008 15:38:56 +0800,

Quoted 20 lines · Wu Fengguang

Quoted 19 lines

Quoted 13 lines

Quoted 12 lines

sound/pci/hda/hda_eld.c

Quoted 9 lines

sound/pci/hda/hda_eld.c new file +6 -0

+static inline unsigned char grab_bits(const unsigned char *buf,
+						int byte, int lowbit, int bits)
+{
+	BUG_ON(lowbit > 7);
+	BUG_ON(bits > 8);
+	BUG_ON(bits <= 0);

Can it be rather BUILD_BUG_ON(), BTW?
Or, hmm, doesn't work if it's an inline function?

Quoted 1 line

Yes, converted to BUILD_BUG_ON() and it compiles OK.

The question is whether this really triggers the build error properly. Could you check it, simply by changing the caller of grab_bits() with some invalid values? Then you should get a compile error.

Quoted 6 lines

Quoted 1 line

BUILD_BUG_ON() won't emit errors! So use BUG_ON()?

Try to make grab_bits() a macro and check whether BUILD_BUG_ON() works. I think it won't be too bad to use a macro for such a pretty simple case. If the resultant code looks too ugly, we should switch back to BUG_ON().

OK, I'm fine with a macro.

Quoted 2 lines

The difference is that BUILD_BUG_ON() would add no real code while BUG_ON() is a pure run-time check.

Quoted 2 lines

But the code should be optimize away by gcc when the constant expression is false?

Well, I think BUG_ON() code remains in this case because it's no constant check as it's in a function (although inlined). Otherwise BUILD_BUG_ON() should have worked.

Quoted 1 line · Wu Fengguang

Create hda_eld.c for ELD routines and proc interface.

Hi,

Just testing this and your multichannel HDMI code over here but it doesn't seem to get ELD data for my setup. Intel g45-id board with an Yamaha RX-v1800 receiver which is HDMI 1.3 capable.

shane@chintoka:~$ cat /proc/asound/Intel/eld#3
monitor name
connection_type         HDMI
eld_version             [0x0] reserved
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                [0x0]
sad_count               0

2ch audio is coming through just fine over HDMI though so the connection itself is there.

Quoted 9 lines · Wu Fengguang

Quoted 7 lines · Shane W

Quoted 1 line · Wu Fengguang

Create hda_eld.c for ELD routines and proc interface.

Just testing this and your multichannel HDMI code over here but it doesn't seem to get ELD data for my setup. Intel g45-id board with an Yamaha RX-v1800 receiver which is HDMI 1.3 capable.

Quoted 2 lines

Do you run the latest xorg intel driver? Also dmesg should tell us something if anything goes wrong with ELD retrieving/parsing.

Yes though Xorg wasn't running when I was doing the audio tests. Pure console at that point but I fired up Xorg which is latest git as of today but still no ELD

population. When Xorg starts, I get this in dmesg:
[drm] Initialized i915 1.6.0 20080730 on minor 0 [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[drm:i915_gem_object_pin] *ERROR* Failure to bind:

-12<6>HDMI intrinsic event: PD=1 ELDV=1

Quoted 10 lines · Shane W

Quoted 9 lines · Wu Fengguang

Quoted 7 lines · Shane W

Quoted 1 line · Wu Fengguang

Create hda_eld.c for ELD routines and proc interface.

Just testing this and your multichannel HDMI code over here but it doesn't seem to get ELD data for my setup. Intel g45-id board with an Yamaha RX-v1800 receiver which is HDMI 1.3 capable.

Quoted 6 lines

Quoted 2 lines

Do you run the latest xorg intel driver? Also dmesg should tell us something if anything goes wrong with ELD retrieving/parsing.

Yes though Xorg wasn't running when I was doing the audio tests. Pure console at that point but I fired up Xorg which is latest git as of today but still no ELD

Yeah sorry I missed one note. The xorg git tree only contains the audio output enabling patches, but not yet ELD transferring patches. (the ELD data flow is monitor => video driver => audio driver) I called for the Xorg ELD enabling patches from Ma Ling just after replying to your email. He should send the patches soon.

Hi,

Ok, it appears to be the kernel I was using. Going to a 2.6.27 kernel rather than 2.6.28-rc fixed the segfault. So now I get ELD data though 5.1 PCM isn't quite there yet. Here's the ELD info.

HDMI intrinsic event: PD=1 ELDV=1
detected monitor Haier TV*** at connection type HDMI supports coding type LPCM: channels = 2, rates = 44100 48000 88200 176400 192000 384000, bits = supports coding type LPCM: channels = 8, rates = 44100 48000 88200 176400 192000 384000, bits =

supports coding type AC-3: channels = 6, rates = 44100 48000 88200, max bitrate = 640000
supports coding type DTS: channels = 7, rates = 44100 48000 88200 176400 192000, max bitrate = 1536000 supports coding type DSD (One Bit Audio): channels = 6, rates = 48000

set status page addr 0x08360000 [drm:i915_getparam] *ERROR* Unknown parameter 5

shane@chintoka:~$ cat /proc/asound/Intel/eld#3
monitor name            Haier TV***
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x1] CEA-861
manufacture_id          0x4148
product_id              0xb01
port_id                 0x0
support_hdcp            0
support_ai              0
audio_sync_delay        0
speakers                [0x0]
sad_count               8
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x1ee0] 44100 48000 88200 176400
192000 384000
sad0_bits               [0xe0000]
sad1_coding_type        [0x1] LPCM
sad1_channels           8
sad1_rates              [0x1ee0] 44100 48000 88200 176400
192000 384000
sad1_bits               [0xe0000]
sad2_coding_type        [0x2] AC-3
sad2_channels           6
sad2_rates              [0xe0] 44100 48000 88200
sad2_max_bitrate        640000
sad3_coding_type        [0x7] DTS
sad3_channels           7
sad3_rates              [0x6e0] 44100 48000 88200 176400
192000
sad3_max_bitrate        1536000
sad4_coding_type        [0x9] DSD (One Bit Audio)
sad4_channels           6
sad4_rates              [0x40] 48000

sad5_coding_type        [0x0] undefined
sad5_channels           1
sad5_rates              [0x0]
sad6_coding_type        [0x0] undefined
sad6_channels           1
sad6_rates              [0x0]
sad7_coding_type        [0x0] undefined
sad7_channels           1
sad7_rates              [0x0]

The speakers 0 line is a bit confusing, not sure if that's

what's doing it. I am using:
aplay 51test.wav

which I have put here:
http://www.csy.ca/~shane/51test.wav

Shane

Quoted 50 lines · Wu Fengguang

Thanks Shane!

Ma Ling: do you have a quick fix for it? Or shall I look into it?

Thank you,
Fengguang

Quoted 42 lines · Shane W

Quoted 3 lines · Wu Fengguang

I managed to update the last working Xorg ELD patches to the latest git tree, and they compile flawlessly. The attached 2 patches are for xf86-video-intel/ and xserver/ respectively.

They do compile but I can't get them to run. Here's the Xorg backtrace when starting. I'm having trouble generating a core but I'll work on getting gdb output if needed.

Backtrace:
0: /opt/gfx-test/bin/Xorg(xorg_backtrace+0x26) [0x4ebbb6]
1: /opt/gfx-test/bin/Xorg(xf86SigHandler+0x39) [0x495b49]

2: /lib/libc.so.6 [0x7f2d1648bf60]
3:
/opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so(gen4_render_state_cleanup+0x1c) [0x7f2d14ebab9c]
4: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so [0x7f2d14e92dfd]
5: /opt/gfx-test/bin/Xorg(AbortDDX+0x8d) [0x4690fd]
6: /opt/gfx-test/bin/Xorg(AbortServer+0x1d) [0x4f505d]
7: /opt/gfx-test/bin/Xorg(LogVMessageVerb+0) [0x4f5700]
8:
/opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so(i830_bind_all_memory+0x102) [0x7f2d14e99592]
9: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so [0x7f2d14e93ad0]
10: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so [0x7f2d14e950f8]
11: /opt/gfx-test/bin/Xorg(AddScreen+0x1c6) [0x431086]
12: /opt/gfx-test/bin/Xorg(InitOutput+0x241) [0x469ae1]
13: /opt/gfx-test/bin/Xorg(main+0x205) [0x431795]
14: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f2d164781a6]
15: /opt/gfx-test/bin/Xorg [0x430dd9]

It seems to be the xserver patch that's doing it. When they are both unapplied, X starts fine, when the Xserver patch is applied, we segfault, when the intel is applied alone, it starts fine and when both are applied the segfault returns.

Shane

Fix bugs on printing the ELD sample bits.

Signed-off-by Wu Fengguang <[email protected]>

Quoted 8 lines · Wu Fengguang

Quoted 7 lines

supports coding type AC-3: channels = 6, rates = 44100 48000 88200, max bitrate = 640000
supports coding type DTS: channels = 7, rates = 44100 48000 88200 176400 192000, max bitrate = 1536000 supports coding type DSD (One Bit Audio): channels = 6, rates = 48000

Quoted 2 lines

It's weird that DTS supports 7 channels while DSD supports 6. DTS is simple the compressed form of DSD.

Hmm, I thought DTS was just another way of compressing PCM whereas DSD is the format used on SACD disks, IE 6 channel.
http://en.wikipedia.org/wiki/Direct_Stream_Digital

Quoted 4 lines

Quoted 1 line

The speakers 0 line is a bit confusing, not sure if that's

Yes it's unexpected. Do you know its real speaker numbers and allocations? Does it provide some number of line-out ports?

There are six speakers connected, fl, ct, fr, rl, rr and lfe.

Quoted 7 lines

Quoted 5 lines

what's doing it. I am using:
aplay 51test.wav

which I have put here:
http://www.csy.ca/~shane/51test.wav

I hear only "front left" and "front right" in my T61 :-)

Yeah, you should get:
Front left
Center
Rear left
Rear right
and a little boom from the sub

If you encode 51test.wav to ac3 and stream through hdmi directly, it does this properly.

Quoted 2 lines · Wu Fengguang

Yes it's unexpected. Do you know its real speaker numbers and allocations? Does it provide some number of line-out ports?

There are six speakers connected, fl, ct, fr, rl, rr and lfe.

Quoted 6 lines · Shane W

Quoted 2 lines · Wu Fengguang

Yes it's unexpected. Do you know its real speaker numbers and allocations? Does it provide some number of line-out ports?

There are six speakers connected, fl, ct, fr, rl, rr and lfe.

Hi Shane,

Apply this patch and run "echo speakers f > /proc/asound/card0/eld\#3". That will make the ELD "speakers" field right.

Thanks,
Fengguang
---
support writing to the ELD proc file

Allow users to fix quicks of ELD ROMs by writing new values to the ELD proc interface. The format is one or more lines of "name hex_value".

Users can add/remove/modify up to 32 SAD(Short Audio Descriptor) entries.

Signed-off-by Wu Fengguang <[email protected]>

---
 sound/pci/hda/hda_eld.c |   56 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

sound/pci/hda/hda_eld.c +56 -0

@@ -500,6 +500,59 @@ static void hdmi_print_eld_info(struct s
 		hdmi_print_sad_info(i, e->sad + i, buffer);
 }
 
+static void hdmi_write_eld_item(struct snd_info_entry *entry,
+				struct snd_info_buffer *buffer)
+{
+	struct hdmi_eld *e = entry->private_data;
+	char line[64];
+	char name[64];
+	char *sname;
+	long long val;
+	int n;
+
+	while (!snd_info_get_line(buffer, line, sizeof(line))) {
+		if (sscanf(line, "%s %llx", name, &val) != 2)
+			continue;
+		if (!strcmp(name, "connection_type"))
+			e->conn_type = val;
+		else if (!strcmp(name, "port_id"))
+			e->port_id = val;
+		else if (!strcmp(name, "support_hdcp"))
+			e->support_hdcp = val;
+		else if (!strcmp(name, "support_ai"))
+			e->support_ai = val;
+		else if (!strcmp(name, "audio_sync_delay"))
+			e->aud_synch_delay = val;
+		else if (!strcmp(name, "speakers"))
+			e->spk_alloc = val;
+		else if (!strcmp(name, "sad_count"))
+			e->sad_count = val;
+		else if (!strncmp(name, "sad", 3)) {
+			sname = name + 4;
+			n = name[3] - '0';
+			if (name[4] >= '0' && name[4] <= '9') {
+				sname++;
+				n = 10 * n + name[4] - '0';
+			}
+			if (n < 0 || n > 31) /* double the CEA limit */
+				continue;
+			if (!strcmp(sname, "_coding_type"))
+				e->sad[n].format = val;
+			else if (!strcmp(sname, "_channels"))
+				e->sad[n].channels = val;
+			else if (!strcmp(sname, "_rates"))
+				e->sad[n].rates = val;
+			else if (!strcmp(sname, "_bits"))
+				e->sad[n].sample_bits = val;
+			else if (!strcmp(sname, "_max_bitrate"))
+				e->sad[n].max_bitrate = val;
+			if (n >= e->sad_count)
+				e->sad_count = n + 1;
+		}
+	}
+}
+
+
 int snd_hda_eld_proc_new(struct hda_codec *codec, struct hdmi_eld *eld)
 {
 	char name[32];

@@ -512,6 +565,9 @@ int snd_hda_eld_proc_new(struct hda_code
 		return err;
 
 	snd_info_set_text_ops(entry, eld, hdmi_print_eld_info);
+	entry->c.text.write = hdmi_write_eld_item;
+	entry->mode |= S_IWUSR;
+
 	return 0;
 }
 

At Fri, 21 Nov 2008 11:41:50 +0800,

Quoted 22 lines · Wu Fengguang

Quoted 6 lines · Shane W

Quoted 2 lines · Wu Fengguang

Yes it's unexpected. Do you know its real speaker numbers and allocations? Does it provide some number of line-out ports?

There are six speakers connected, fl, ct, fr, rl, rr and lfe.

Hi Shane,

Apply this patch and run "echo speakers f > /proc/asound/card0/eld\#3". That will make the ELD "speakers" field right.

Thanks,
Fengguang
---
support writing to the ELD proc file

Allow users to fix quicks of ELD ROMs by writing new values to the ELD proc interface. The format is one or more lines of "name hex_value".

Quoted 3 lines

Users can add/remove/modify up to 32 SAD(Short Audio Descriptor) entries.

Signed-off-by Wu Fengguang <[email protected]>

This is a nice feature, so I applied now as is. Please give an incremental patch if you need more fixes.