[CaptainObvious]

Hello,

I have a Acer Aspire Revo R3700 which I'm very happy with. I was slightly (pleasantly) surprised when I upgraded XBMC (to the latest from git) recently and found that I could select a new HDMI device in the audio output setting. This new device had parts of my receivers name in it, so something is now supporting some HDMI magic which it didn't before.

Anywho, I have a friend who bought an Acer Aspire Revo RL70. We got the sound "working" (there were some slight oddities in it, surely due to our weak ALSA-fu) using some manual hacks, but as things seem to be more automagic in newer XBMC's, I suggested he check out the source from the repository and build it himself, and see if a device akin to the new one I got would appear.

The end result was slightly disappointing. Though he loves the new features of the new XBMC, for him there's no new audio output device. In addition, the "custom" option which we used to get sound using the old version is gone.

He could simply switch back to the old version, but I can't help shake the feeling that it "should work".

What am I missing here? My receiver is HDMI 1.4, the one he's using is HDMI 1.3c (could this be an issue?). We're both running debian testing. My system uses a Nvidia chip, his uses ATI (AMD).

Anyone with some HDMI-fu who understands what's going on?

[Chris!]

Have you tried a different HDMI cable (or the same one for both computers) just in case that's affecting it.

[CaptainObvious]

Have you tried a different HDMI cable (or the same one for both computers) just in case that's affecting it.

No, I didn't try that, and it's sort of a pain to do so as we live quite distance from each other.

But I want to reiterate that the sound sort-of works with an older XBMC release, and unless there's some sort of control-data which is sent over a special wires which are only needed for a newer XBMC, I'm not really sure that a cable change even theoretically could explain or fix this problem. (Feel free to correct me if I'm wrong).

One of the problems is - as I mentioned above - that we live some distance from each other. Otherwise I would have been able to sit down and do a more thorough investigation myself, but my friend - though very technically apt - doesn't have the same amount of time and patience to figure these things out as I do. Since it Just Worked™ for me I never had any reason to dig into it, so I don't have a clue where to start looking.

Any hints on relevant logs or /proc nodes to inspect are welcome.

[Snippo]

Have you tried this:
http://forum.xbmc.org/showthread.php?tid...pid1092039

?

[CaptainObvious]

Quick followup:

I noticed that on my system the kernel actually detects my receiver and its capabilities:

[ 29.251182] HDMI hot plug event: Codec=1 Pin=5 Presence_Detect=1 ELD_Valid=0
[ 29.256058] HDMI status: Codec=1 Pin=5 Presence_Detect=1 ELD_Valid=0
[ 29.280628] HDMI hot plug event: Codec=1 Pin=5 Presence_Detect=1 ELD_Valid=1
[ 29.288034] HDMI status: Codec=1 Pin=5 Presence_Detect=1 ELD_Valid=1
[ 30.056032] HDMI: detected monitor DENON-AVAMP
[ 30.056035] at connection type HDMI
[ 30.056043] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC
[ 30.056054] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 88200 96000 176400 192000, bits = 16 20 24
[ 30.056063] HDMI: supports coding type DTS: channels = 6, rates = 44100 48000 88200 96000, max bitrate = 1536000
[ 30.056071] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000
[ 30.056079] HDMI: supports coding type DTS-HD: channels = 8, rates = 44100 48000 88200 96000 176400 192000
[ 30.056086] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000
[ 30.056095] HDMI: supports coding type MLP (Dolby TrueHD): channels = 6, rates = 44100 48000 88200 96000 176400 192000
[ 30.056102] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 44100 48000 88200 96000

(Yes, I know Denon are pseudo-scientific screwballs who sell $500 Ethernet cables. And yes, I'm very uncomfortable having supported them).

Anywho; on my friend's system there was no ELD_Valid=1, no information from the receiver at all, and in the XBMC log there was a message along the line of ELData missing for a device. I wanted some way to verify that was indeed the problem, I suggested he install another linux distro to see if it would help.

So he installed Ubuntu, and then installed some ATI-non-free-package, and then he got the ELD_Valid=1, and it listed the capabilities of the receiver in dmesg. I was (perhaps wrongly) assuming this was a prerequisite for xbmc being able to list HDMI output device.

He built and ran xbmc but it still won't show the expected HDMI entries for the audio device settings. He hasn't had time to check the what the xbmc log says, but I hope I'll find out later today.

[ezeki]

CaptainObvious I am having the same problem and have the same hardware Please post your findings as I have followed the below with no success

In terminal:
Code: alsamixer
and unmute all devices.

Then

Code: aplay -l
find the device you wish to use, remember the value for "card" and "device".

Then change the settings in XBMC as follows:
Code:
Custom audio device: plughw:"card","device" (mine is 1,3)
Custom passthrough device: plughw:"card","device" (mine is 1,3)
With "card" and "device" set to the values you found with aplay -l.

[CaptainObvious]

So he installed Ubuntu, and then installed some ATI-non-free-package, and then he got the ELD_Valid=1, and it listed the capabilities of the receiver in dmesg.

Apparently I had misunderstood. The kernel does report ELD_Valid=1, but it doesn't list any capabilities as it does on my system. Also, cat:ing the eld-nodes found somewhere under /proc/asound shows only eld_valid=0 (whereas on my system I get lots of information from some of these nodes). It's somewhat peculiar to me that on his system, during boot, it says ELD_Valid=1, but none of the proc-nodes say eld_valid=1.

Some reports suggest these types of issues can be due to problems with the 3.2 kernel and may be fixed in 3.3 or 3.4.