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)