[alsa-devel] HDMI LPCM (7.1) with AMD/FGLRX
Hello.
I'm wondering if there's any ongoing development on multichannel sound support for HDMI - LPCM/5.1/7.1, not bitstreamed audio such as DTS/AC3 (which works). I've tried both a AMD HD 4870 and AMD HD 6870, on both 2 channel and bitstreamed audio works with ALSA, but not LPCM. LPCM works perfectly (5.1, 7.1) on Windows.
According to the mailing list there seem to have been some activity in this area (January or so), but no success. I'd gladly try out patches.
My setup is: Arch Linux 64 bit fglrx 11.7 alsa 1.0.24 HD 6870 -> HDMI -> Denon AVR-1909 (Receiver) -> HDTV
-- aplay -L
hdmi:CARD=Generic,DEV=0 HD-Audio Generic, HDMI 0 HDMI Audio Output -- speaker-test -D hw:2,3 -c 6
speaker-test 1.0.24.2
Playback device is hw:2,3 Stream parameters are 48000Hz, S16_LE, 6 channels Using 16 octaves of pink noise Channels count (6) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument -- speaker-test -D hw:2,3 -c 8
speaker-test 1.0.24.2
Playback device is hw:2,3 Stream parameters are 48000Hz, S16_LE, 8 channels Using 16 octaves of pink noise Channels count (8) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument --
At Sun, 7 Aug 2011 21:17:46 +0200, Andrée 'Glaucous' wrote:
Hello.
I'm wondering if there's any ongoing development on multichannel sound support for HDMI - LPCM/5.1/7.1, not bitstreamed audio such as DTS/AC3 (which works). I've tried both a AMD HD 4870 and AMD HD 6870, on both 2 channel and bitstreamed audio works with ALSA, but not LPCM. LPCM works perfectly (5.1, 7.1) on Windows.
According to the mailing list there seem to have been some activity in this area (January or so), but no success. I'd gladly try out patches.
Check whether your HDMI codec chip is processed via patch_generic_hdmi() in patch_hdmi.c. Some ATI codecs are via patch_atihdmi() and it doesn't support multi-channel LPCM.
If it's through patch_generic_hdmi(), basically it should work as is, since the very same function is used by Intel and Nvidia HDMI, too, and LPCM works on them. Of course, some unknown ATI-specific things might be missing. But first check whether ELD validity is set, i.e. whether the video driver passes the right ELD to HDMI auido side.
Takashi
/proc/asound/Generic/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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital 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 Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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=03, enabled=1 Connection: 1 0x02 <<
Since it's R6xx, it should be processed by patch_generic_hdmi().
patch_hdmi.c ..
id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi <<
Although this might not be proof enough, how best would I debug and check if it's using patch_generic_hdmi? I also checked the ELD, while outputting video to HDMI (to make sure it's enabled) to the screen.
(Generic is symlink to card2)
/proc/asound/Generic/eld#0.0
monitor_present 0 eld_valid 1 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 <<
It seems to think that it's valid at least, but I doesn't seem to output any information about it (speaker count etc).
On 8 August 2011 09:16, Takashi Iwai tiwai@suse.de wrote:
At Sun, 7 Aug 2011 21:17:46 +0200, Andrée 'Glaucous' wrote:
Hello.
I'm wondering if there's any ongoing development on multichannel sound support for HDMI - LPCM/5.1/7.1, not bitstreamed audio such as DTS/AC3 (which works). I've tried both a AMD HD 4870 and AMD HD 6870, on both 2 channel and bitstreamed audio works with ALSA, but not LPCM. LPCM works perfectly
(5.1,
7.1) on Windows.
According to the mailing list there seem to have been some activity in
this
area (January or so), but no success. I'd gladly try out patches.
Check whether your HDMI codec chip is processed via patch_generic_hdmi() in patch_hdmi.c. Some ATI codecs are via patch_atihdmi() and it doesn't support multi-channel LPCM.
If it's through patch_generic_hdmi(), basically it should work as is, since the very same function is used by Intel and Nvidia HDMI, too, and LPCM works on them. Of course, some unknown ATI-specific things might be missing. But first check whether ELD validity is set, i.e. whether the video driver passes the right ELD to HDMI auido side.
Takashi
At Mon, 8 Aug 2011 11:32:43 +0200, Andrée 'Glaucous' wrote:
/proc/asound/Generic/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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital 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 Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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=03, enabled=1 Connection: 1 0x02 <<
Since it's R6xx, it should be processed by patch_generic_hdmi().
patch_hdmi.c ..
id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi <<
Although this might not be proof enough, how best would I debug and check if it's using patch_generic_hdmi?
Don't worry, if it has ELD file, it alone means it's generic-HDMI parser.
I also checked the ELD, while outputting video to HDMI (to make sure it's enabled) to the screen.
(Generic is symlink to card2)
/proc/asound/Generic/eld#0.0
monitor_present 0 eld_valid 1 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 <<
It seems to think that it's valid at least, but I doesn't seem to output any information about it (speaker count etc).
The monitor isn't present, so it seems that it didn't get ELD info. The information is taken from the pin-sense verb, so you can even get it externally via hda-verb for confirming whether the information is correct or not.
Takashi
Turns out hda-verb is somewhat "out of my league". This is what I came up with, but I'm not sure what PARAMETER I should use in order to get something useful, I'm actually not sure if it's the correct nid either. If you could point me (even more) in the correct direction that'd be good, so that I can confirm it.
# hda-verb /dev/snd/hwC2D0 0x0 GET_PIN_SENSE VENDOR_ID
It seems odd that the driver isn't sending monitor_present true, since it very much is present, and used. Then again fglrx aren't the nicest drivers to work with.
On 8 August 2011 11:52, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 11:32:43 +0200, Andrée 'Glaucous' wrote:
/proc/asound/Generic/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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital 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 Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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=03, enabled=1 Connection: 1 0x02 <<
Since it's R6xx, it should be processed by patch_generic_hdmi().
patch_hdmi.c ..
id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi <<
Although this might not be proof enough, how best would I debug and check if it's using patch_generic_hdmi?
Don't worry, if it has ELD file, it alone means it's generic-HDMI parser.
I also checked the ELD, while outputting video to HDMI (to make sure it's enabled) to the screen.
(Generic is symlink to card2)
/proc/asound/Generic/eld#0.0
monitor_present 0 eld_valid 1 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 <<
It seems to think that it's valid at least, but I doesn't seem to output any information about it (speaker count etc).
The monitor isn't present, so it seems that it didn't get ELD info. The information is taken from the pin-sense verb, so you can even get it externally via hda-verb for confirming whether the information is correct or not.
Takashi
At Mon, 8 Aug 2011 12:22:26 +0200, Andrée 'Glaucous' wrote:
Turns out hda-verb is somewhat "out of my league". This is what I came up with, but I'm not sure what PARAMETER I should use in order to get something useful, I'm actually not sure if it's the correct nid either. If you could point me (even more) in the correct direction that'd be good, so that I can confirm it.
# hda-verb /dev/snd/hwC2D0 0x0 GET_PIN_SENSE VENDOR_ID
It should be like:
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0
The pin NID is 0x03.
Takashi
On 8 August 2011 11:52, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 11:32:43 +0200, Andrée 'Glaucous' wrote:
/proc/asound/Generic/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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital 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 Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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=03, enabled=1 Connection: 1 0x02 <<
Since it's R6xx, it should be processed by patch_generic_hdmi().
patch_hdmi.c ..
id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi <<
Although this might not be proof enough, how best would I debug and check if it's using patch_generic_hdmi?
Don't worry, if it has ELD file, it alone means it's generic-HDMI parser.
I also checked the ELD, while outputting video to HDMI (to make sure it's enabled) to the screen.
(Generic is symlink to card2)
/proc/asound/Generic/eld#0.0
monitor_present 0 eld_valid 1 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 <<
It seems to think that it's valid at least, but I doesn't seem to output any information about it (speaker count etc).
The monitor isn't present, so it seems that it didn't get ELD info. The information is taken from the pin-sense verb, so you can even get it externally via hda-verb for confirming whether the information is correct or not.
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Thanks.
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0 nid = 0x3, verb = 0xf09, param = 0x0 value = 0xffffffff
With monitor connected and outputting.
On 8 August 2011 14:43, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 12:22:26 +0200, Andrée 'Glaucous' wrote:
Turns out hda-verb is somewhat "out of my league". This is what I came up with, but I'm not sure what PARAMETER I should use
in
order to get something useful, I'm actually not sure if it's the correct nid either. If you could point me (even more) in the correct direction that'd be good, so that I can confirm it.
# hda-verb /dev/snd/hwC2D0 0x0 GET_PIN_SENSE VENDOR_ID
It should be like:
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0
The pin NID is 0x03.
Takashi
On 8 August 2011 11:52, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 11:32:43 +0200, Andrée 'Glaucous' wrote:
/proc/asound/Generic/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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital 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 Device: name="HDMI 0", type="HDMI", device=3 Converter: stream=1, channel=0 Digital: Enabled Digital category: 0x0 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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=03, enabled=1 Connection: 1 0x02 <<
Since it's R6xx, it should be processed by patch_generic_hdmi().
patch_hdmi.c ..
id = 0x1002aa01, .name = "R6xx HDMI", .patch = patch_generic_hdmi <<
Although this might not be proof enough, how best would I debug and check if it's using patch_generic_hdmi?
Don't worry, if it has ELD file, it alone means it's generic-HDMI parser.
I also checked the ELD, while outputting video to HDMI (to make sure it's enabled) to the screen.
(Generic is symlink to card2)
/proc/asound/Generic/eld#0.0
monitor_present 0 eld_valid 1 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 <<
It seems to think that it's valid at least, but I doesn't seem to output any information about it (speaker count etc).
The monitor isn't present, so it seems that it didn't get ELD info. The information is taken from the pin-sense verb, so you can even get it externally via hda-verb for confirming whether the information is correct or not.
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Mon, 8 Aug 2011 16:43:31 +0200, Andrée 'Glaucous' wrote:
Thanks.
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0 nid = 0x3, verb = 0xf09, param = 0x0 value = 0xffffffff
This looks pretty invalid.
With monitor connected and outputting.
So, either codec or the a driver is too lazy to give the info.
Also, looking at your codec proc file, the codec doesn't give the right channel count, too.
What happens with the patch below?
Takashi
--- diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 19cb72d..4da81b3 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -923,6 +923,7 @@ static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
memset(eld, 0, sizeof(*eld));
+ printk(KERN_INFO "XXX HDMI pin_sense = 0x%x\n", present); eld->monitor_present = !!(present & AC_PINSENSE_PRESENCE); if (eld->monitor_present) eld->eld_valid = !!(present & AC_PINSENSE_ELDV); @@ -996,6 +997,7 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid)
chans = get_wcaps(codec, cvt_nid); chans = get_wcaps_channels(chans); + chans = 8; /* XXX */
cvt_idx = spec->num_cvts; per_cvt = &spec->cvts[cvt_idx];
I'm not quite sure which version (of patch_hdmi.c) you are using, since the patch fails on kernel 3.0-stable.
-- patching file sound/pci/hda/patch_hdmi.c Hunk #1 FAILED at 923. Hunk #2 FAILED at 996. 2 out of 2 hunks FAILED -- saving rejects to file sound/pci/hda/patch_hdmi.c.rej
On 8 August 2011 16:58, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 16:43:31 +0200, Andrée 'Glaucous' wrote:
Thanks.
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0 nid = 0x3, verb = 0xf09, param = 0x0 value = 0xffffffff
This looks pretty invalid.
With monitor connected and outputting.
So, either codec or the a driver is too lazy to give the info.
Also, looking at your codec proc file, the codec doesn't give the right channel count, too.
What happens with the patch below?
Takashi
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 19cb72d..4da81b3 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -923,6 +923,7 @@ static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
memset(eld, 0, sizeof(*eld));
printk(KERN_INFO "XXX HDMI pin_sense = 0x%x\n", present); eld->monitor_present = !!(present & AC_PINSENSE_PRESENCE); if (eld->monitor_present) eld->eld_valid = !!(present & AC_PINSENSE_ELDV);@@ -996,6 +997,7 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid)
chans = get_wcaps(codec, cvt_nid); chans = get_wcaps_channels(chans);
chans = 8; /* XXX */ cvt_idx = spec->num_cvts; per_cvt = &spec->cvts[cvt_idx];
Okay, after waking up and stopped being stupid, I cloned latest alsa-kernel, this however still resulted in your patch failing, but I managed to install it manually.
I still can't run speaker-test with more than 2 channels. (HDMI is card1 now) -- /proc/asound/card1/eld#0.0 monitor_present 1 eld_valid 1 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 [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH sad_count 0 --
Now monitor is present (which I should add, it also was when I updated to kernel 3.0 without any alsa patch), and there are many more channels, which is probably because due to your patch hardcoding the channel count.
-- 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 [0x5]: PCM AC3 Default Amp-In caps: N/A Default Amp-Out caps: N/A 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 Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital 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 Pincap 0x00000094: OUT Detect HDMI Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=03, enabled=1 Connection: 1 0x02 --
2011/8/8 Andrée 'Glaucous' glakke1@gmail.com
I'm not quite sure which version (of patch_hdmi.c) you are using, since the patch fails on kernel 3.0-stable.
-- patching file sound/pci/hda/patch_hdmi.c Hunk #1 FAILED at 923. Hunk #2 FAILED at 996. 2 out of 2 hunks FAILED -- saving rejects to file sound/pci/hda/patch_hdmi.c.rej
On 8 August 2011 16:58, Takashi Iwai tiwai@suse.de wrote:
At Mon, 8 Aug 2011 16:43:31 +0200, Andrée 'Glaucous' wrote:
Thanks.
# hda-verb /dev/snd/hwC2D0 0x03 GET_PIN_SENSE 0 nid = 0x3, verb = 0xf09, param = 0x0 value = 0xffffffff
This looks pretty invalid.
With monitor connected and outputting.
So, either codec or the a driver is too lazy to give the info.
Also, looking at your codec proc file, the codec doesn't give the right channel count, too.
What happens with the patch below?
Takashi
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 19cb72d..4da81b3 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -923,6 +923,7 @@ static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
memset(eld, 0, sizeof(*eld));
printk(KERN_INFO "XXX HDMI pin_sense = 0x%x\n", present); eld->monitor_present = !!(present & AC_PINSENSE_PRESENCE); if (eld->monitor_present) eld->eld_valid = !!(present & AC_PINSENSE_ELDV);@@ -996,6 +997,7 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid)
chans = get_wcaps(codec, cvt_nid); chans = get_wcaps_channels(chans);
chans = 8; /* XXX */ cvt_idx = spec->num_cvts; per_cvt = &spec->cvts[cvt_idx];
At Tue, 9 Aug 2011 00:13:24 +0200, Andrée 'Glaucous' wrote:
Okay, after waking up and stopped being stupid, I cloned latest alsa-kernel,
Use sound git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
this however still resulted in your patch failing, but I managed to install it manually.
I still can't run speaker-test with more than 2 channels.
Give the kernel message. It should show the raw value.
(HDMI is card1 now)
/proc/asound/card1/eld#0.0 monitor_present 1 eld_valid 1 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 [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH sad_count 0
So, this means it's likely 0xffffffff or such.
--
Now monitor is present (which I should add, it also was when I updated to kernel 3.0 without any alsa patch), and there are many more channels, which is probably because due to your patch hardcoding the channel count.
No, the speaker configs read above are irrelevant from the channel count.
Takashi
Current kernel message (using alsa-kernel, I'll clone and build your git soon, got some internet problems at the moment): [ 147.334343] XXX HDMI pin_sense = 0x7fffffff [ 147.565059] XXX HDMI pin_sense = 0x7fffffff [ 153.248894] XXX HDMI pin_sense = 0xffffffff [ 153.250443] XXX HDMI pin_sense = 0xffffffff [ 189.475073] XXX HDMI pin_sense = 0x7fffffff [ 189.698017] XXX HDMI pin_sense = 0x7fffffff [ 196.664565] XXX HDMI pin_sense = 0xffffffff [ 196.666079] XXX HDMI pin_sense = 0xffffffff
It recognizes when I take the cable in and out, or toggles display output (0xffffffff when connected).
On 9 August 2011 09:19, Takashi Iwai tiwai@suse.de wrote:
At Tue, 9 Aug 2011 00:13:24 +0200, Andrée 'Glaucous' wrote:
Okay, after waking up and stopped being stupid, I cloned latest
alsa-kernel,
Use sound git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
this however still resulted in your patch failing, but I managed to install it manually.
I still can't run speaker-test with more than 2 channels.
Give the kernel message. It should show the raw value.
(HDMI is card1 now)
/proc/asound/card1/eld#0.0 monitor_present 1 eld_valid 1 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 [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH
TC
FCH sad_count 0
So, this means it's likely 0xffffffff or such.
--
Now monitor is present (which I should add, it also was when I updated to kernel 3.0 without any alsa patch), and there are many more channels, which is probably because due to your patch hardcoding the channel count.
No, the speaker configs read above are irrelevant from the channel count.
Takashi
At Tue, 9 Aug 2011 11:37:37 +0200, Andrée 'Glaucous' wrote:
Current kernel message (using alsa-kernel, I'll clone and build your git soon, got some internet problems at the moment): [ 147.334343] XXX HDMI pin_sense = 0x7fffffff [ 147.565059] XXX HDMI pin_sense = 0x7fffffff [ 153.248894] XXX HDMI pin_sense = 0xffffffff [ 153.250443] XXX HDMI pin_sense = 0xffffffff [ 189.475073] XXX HDMI pin_sense = 0x7fffffff [ 189.698017] XXX HDMI pin_sense = 0x7fffffff [ 196.664565] XXX HDMI pin_sense = 0xffffffff [ 196.666079] XXX HDMI pin_sense = 0xffffffff
It recognizes when I take the cable in and out, or toggles display output (0xffffffff when connected).
OK, it's good to know. It means that the pin-sense reports only the pin-detection but nothing else unlike other codecs. So, it's basically bad to use generic HDMI parser for this codec.
And, when you wrote "I still can't run speaker-test with more than 2 channels", do you mean that you got an error? How did you run? With the patch, the driver should take up to 8 channels. If not, something was wrong -- either the patch wrongly applied or the patch wasn't enough.
Takashi
I run speaker-test -D hw:1,3 -c 8 Now it actually worked a bit. The speaker-test runs as it should, but everytime it tries output to "none-two-channel" channel (LFE, Rear Left, Rear Right.. etc), it doesn't output anything. And I can see on the receiver that the (2 channel PCM stream, but should say 7.1 Multichannel) is lost every time except for Front Left/Right channel.
On 9 August 2011 12:05, Takashi Iwai tiwai@suse.de wrote:
At Tue, 9 Aug 2011 11:37:37 +0200, Andrée 'Glaucous' wrote:
Current kernel message (using alsa-kernel, I'll clone and build your git soon, got some internet problems at the moment): [ 147.334343] XXX HDMI pin_sense = 0x7fffffff [ 147.565059] XXX HDMI pin_sense = 0x7fffffff [ 153.248894] XXX HDMI pin_sense = 0xffffffff [ 153.250443] XXX HDMI pin_sense = 0xffffffff [ 189.475073] XXX HDMI pin_sense = 0x7fffffff [ 189.698017] XXX HDMI pin_sense = 0x7fffffff [ 196.664565] XXX HDMI pin_sense = 0xffffffff [ 196.666079] XXX HDMI pin_sense = 0xffffffff
It recognizes when I take the cable in and out, or toggles display output (0xffffffff when connected).
OK, it's good to know. It means that the pin-sense reports only the pin-detection but nothing else unlike other codecs. So, it's basically bad to use generic HDMI parser for this codec.
And, when you wrote "I still can't run speaker-test with more than 2 channels", do you mean that you got an error? How did you run? With the patch, the driver should take up to 8 channels. If not, something was wrong -- either the patch wrongly applied or the patch wasn't enough.
Takashi
At Tue, 9 Aug 2011 12:31:03 +0200, Andrée 'Glaucous' wrote:
I run speaker-test -D hw:1,3 -c 8 Now it actually worked a bit. The speaker-test runs as it should, but everytime it tries output to "none-two-channel" channel (LFE, Rear Left, Rear Right.. etc), it doesn't output anything. And I can see on the receiver that the (2 channel PCM stream, but should say 7.1 Multichannel) is lost every time except for Front Left/Right channel.
Then some information is missing. ATI seems to have implemented LPCM in a vendor-specific way.
Takashi
On 9 August 2011 12:05, Takashi Iwai tiwai@suse.de wrote:
At Tue, 9 Aug 2011 11:37:37 +0200, Andrée 'Glaucous' wrote:
Current kernel message (using alsa-kernel, I'll clone and build your git soon, got some internet problems at the moment): [ 147.334343] XXX HDMI pin_sense = 0x7fffffff [ 147.565059] XXX HDMI pin_sense = 0x7fffffff [ 153.248894] XXX HDMI pin_sense = 0xffffffff [ 153.250443] XXX HDMI pin_sense = 0xffffffff [ 189.475073] XXX HDMI pin_sense = 0x7fffffff [ 189.698017] XXX HDMI pin_sense = 0x7fffffff [ 196.664565] XXX HDMI pin_sense = 0xffffffff [ 196.666079] XXX HDMI pin_sense = 0xffffffff
It recognizes when I take the cable in and out, or toggles display output (0xffffffff when connected).
OK, it's good to know. It means that the pin-sense reports only the pin-detection but nothing else unlike other codecs. So, it's basically bad to use generic HDMI parser for this codec.
And, when you wrote "I still can't run speaker-test with more than 2 channels", do you mean that you got an error? How did you run? With the patch, the driver should take up to 8 channels. If not, something was wrong -- either the patch wrongly applied or the patch wasn't enough.
Takashi
Do you think it might be possible to get in touch with the ATI/AMD developers, and get implementation details? I can't imagine that they don't want LPCM to work with ALSA.
On 9 August 2011 12:35, Takashi Iwai tiwai@suse.de wrote:
At Tue, 9 Aug 2011 12:31:03 +0200, Andrée 'Glaucous' wrote:
I run speaker-test -D hw:1,3 -c 8 Now it actually worked a bit. The speaker-test runs as it should, but everytime it tries output to "none-two-channel" channel (LFE, Rear Left, Rear Right.. etc), it doesn't output anything. And I can see on the receiver that the (2 channel PCM stream, but should say 7.1 Multichannel) is lost every time except for Front Left/Right channel.
Then some information is missing. ATI seems to have implemented LPCM in a vendor-specific way.
Takashi
On 9 August 2011 12:05, Takashi Iwai tiwai@suse.de wrote:
At Tue, 9 Aug 2011 11:37:37 +0200, Andrée 'Glaucous' wrote:
Current kernel message (using alsa-kernel, I'll clone and build your
git
soon, got some internet problems at the moment): [ 147.334343] XXX HDMI pin_sense = 0x7fffffff [ 147.565059] XXX HDMI pin_sense = 0x7fffffff [ 153.248894] XXX HDMI pin_sense = 0xffffffff [ 153.250443] XXX HDMI pin_sense = 0xffffffff [ 189.475073] XXX HDMI pin_sense = 0x7fffffff [ 189.698017] XXX HDMI pin_sense = 0x7fffffff [ 196.664565] XXX HDMI pin_sense = 0xffffffff [ 196.666079] XXX HDMI pin_sense = 0xffffffff
It recognizes when I take the cable in and out, or toggles display
output
(0xffffffff when connected).
OK, it's good to know. It means that the pin-sense reports only the pin-detection but nothing else unlike other codecs. So, it's basically bad to use generic HDMI parser for this codec.
And, when you wrote "I still can't run speaker-test with more than 2 channels", do you mean that you got an error? How did you run? With the patch, the driver should take up to 8 channels. If not, something was wrong -- either the patch wrongly applied or the patch wasn't enough.
Takashi
participants (2)
-
Andrée 'Glaucous' -
Takashi Iwai