Latest firmware outputs HDMI 7.1 channel PCM as 5.1

[tghewett]

The latest firmware (based on 3.10.19+) produces 7.1 channel PCM as 5.1 at the receiver.

Using the current raspberry.org download of Arch Linux with its older firmware produces 7.1 channel PCM as 7.1 channels at the receiver, something went wrong around the time of the up-step from 3.6.x to 3.10.x.

Copying the current *.dat, *.bin and *.elf files to the stock Arch Linux installation makes the problem happen there too. Running a 3.10.19+ kernel built using the Arch Linux config doesn't fix it.

(Also the solution for the previous problem of S/PDIF encoded audio not being decoded at the receiver doesn't work with Arch Linux and 3.10.19+, though it is fine on Raspbian with the same firmware and the same 3.10.19+ source kernel built using the Raspbian config (which Arch Linux won't boot) ... Does the fix need a particular kernel option enabled or disabled? Both had the same *.elf, *.dat and /opt/vc files.)

[popcornmix]

What program are you using to output 7.1 audio?
Already formatted S/PDIF output as stereo PCM requires in config.txt:
no_hdmi_resample=1
hdmi_stream_channels=1

[tghewett]

The 5.1/7.1 problem happens with hello_audio, the same source as provided with a previous issue but set for 8 channels instead of 2.

(Arch Linux now playing 5.1 encoded audio fine)

[popcornmix]

I've just connected an HDMI analyser.

./hello_audio.bin 1 8

reports 8 channels (FL/FR/LFE/FC/RL/RR/FLC/FRC) and no complaints.

Are you sure Arch has the latest hello_audio code? Latest GPU firmware (vcgencmd version)?
It was tweaked when adding proper multichannel PCM support to omxplayer/xbmc.

[tghewett]

The latest hello_audio code, built in a snapshot of 26/11/13, does the same.

At present Arch >doesn't< have the latest *.elf and *.dat firmware, only that which comes in the raspberry.org download, and it works fine, 7.1 channels at the receiver. The problem only starts when updating these to the latest files.

Arch download vcgencmd version:

Jul 19 2013 23:48:50
Copyright (c) 2012 Broadcom
version 8b570d997388ca7989be17029f79180f98465e3c (clean) (release)

version for firmware downloaded on 26/11/13, which has the problem:

Nov 15 2013 14:17:01
Copyright (c) 2012 Broadcom
version 162026b1448f491e97e3b3b57cdca29be6a1d61a (tainted) (release)

I tried copying in the /opt/vc tree from the 26/11/13 firmware, no difference.

A further observation is that (albeit with only 5.1 channels at the receiver) 7.1 channel output has become reliable at 96kHz, previously it kept dropping out unless the RP was overclocked to 1GHz.

[tghewett]

The version numbers seem to have been interpreted as links, here they are respectively:

"8b570d997388ca7989be17029f79180f98465e3c"
"162026b1448f491e97e3b3b57cdca29be6a1d61a"

[popcornmix]

I'd suggest you get the Nov 27th which did have an hdmi audio fix in (fix for "chirping").

Can you try on a different receiver?
Can you try with my hello_audio:
https://dl.dropboxusercontent.com/u/3669512/temp/hello_audio.bin

Can you try with "hdmi_stream_channels=1" removed?

Here is what hdmi analyser shows with "hello_audio.bin 1 8"
https://dl.dropboxusercontent.com/u/3669512/temp/photo.JPG

[tghewett]

I'd suggest you get the Nov 27th which did have an hdmi audio fix in (fix for "chirping").

Have tried today's *.bin, *.dat and *.elf, no change.

Can you try on a different receiver?

Only one receiver unfortunately, Onkyo-based (Teac).

Can you try with my hello_audio

It produces an error: ./hello_audio.bin: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory

Tried creating a .conf in /etc/ld.so.conf.d containing "/opt/vc/lib", then "ldconfig, no change.

Can you try with "hdmi_stream_channels=1" removed?

No change. (I find this isn't needed for 5.1 encoded audio to work BTW, so it seems)

Here is what hdmi analyser shows with "hello_audio.bin 1 8"

That looks nice. Handy item to have around.

[popcornmix]

I'm not very familiar with Arch. I'd imagine it's safe to do

sudo SKIP_KERNEL=1 rpi-update

which would get the latest hello_audio.
Otherwise you could try a raspbian install and then rpi-update it to see if that works.

I'd like to find out if your problem is Arch installation related, or if the Onkyo doesn't like our 7.1 output.

[tghewett]

Just tried a complete reinstall from the latest Raspbian image, followed by "sudo SKIP_KERNEL=1 rpi-update" and then ./hello_audio.bin 1 8", still the same 5.1 channels at the receiver.

[popcornmix]

I've got a Onkyo 606 here
./hello_audio.bin 1 8
and recever displays "MCH PCM 7.1"

[tghewett]

The amp has been set to the "direct" listening mode for this input and audio type, I suspect your Onkyo has much the same set of options. Have tried setting it to "multich", still the same.

Just connected a Mac to it by HDMI and 8-ch PCM is received at the amp as 7.1 channels. Perhaps your Onkyo is more forgiving?

[tghewett]

I am wondering if you can tell me which source files were modified to cause my amp to display 5.1ch instead of 7.1ch (as I still experience it, including with a Raspberry Pi 2 running kernel 3.18). I would like to be able to reverse it but keep a more recent kernel, the RP2 seems unable to build a 3.6 kernel as it came along later. I assume it is the kernel which was changed to cause this and not something in the other firmware files.

[popcornmix]

It's nothing to do with the kernel. It will be the start.elf firmware.
You suggest the problem occurred between "Jul 19 2013 23:48:50" and "Nov 15 2013 14:17:01".
If you could identify the exact firmware revision, I could explain exactly what changed.
I'd suggest you test with a Pi1 (older firmware won't support Pi2) and run:
sudo SKIP_KERNEL=1 rpi-update <hash>
where the hash comes from:
https://github.com/Hexxeh/rpi-firmware/commits/master

(click on a firmware version for the hash). If you identify the first version with the problem, I'll investigate.

[tghewett]

Yes, it starts at hash code 5f4e0ba, Nov 6 2013, just after the bump to kernel 3.10.18. Hash code dc709fa just before it is fine.

[popcornmix]

Unfortunately that update was quite a big rewrite of the multichannel audio code.
You can narrow it down further using the next tree:
https://github.com/Hexxeh/rpi-firmware/commits/next

Can you identify when that tree broke? (It will be near the date you identified).

[tghewett]

Yes, it starts with the commit on 22 Oct 2013, hash code 6f5c2e5. The commit before this on 18 Oct (a7a5b4b) is fine.

[popcornmix]

With latest firmware can you run:

vcgencmd hdmi_channel_map 0x13fac688
/opt/vc/src/hello_pi/hello_audio/hello_audio.bin 1 8

and report what the receiver reports?

[tghewett]

Yes, the "vcgencmd hdmi_channel_map 0x13fac688" command gets 7.1ch PCM back, both for hello_audio and my own app. It also works for the RP2.

[tghewett]

Additional: after running the vcgencmd command the amp now shows 7.1ch PCM for all output formats, e.g. stereo, not just 8ch output. (EDIT: this applies only to the RP2, the original RP is fine)

[popcornmix]

There is a little information of that gencmd here:
raspberrypi/firmware#299 (comment)

Simple solution it to run:

vcgencmd hdmi_channel_map 0

When you have finished with 7.1 audio and want to revert to default behaviour.

Audio infoframe byte 4 is described here. We used to use:
19 "RRC RLC RR RL FC LFE FR FL"
but now use
31 "FRC FLC RR RL FC LFE FR FL"
but you can override that with the hdmi_channel_map gencmd.

[tghewett]

With the current default map, are these symptoms showing up a problem in the amp or is the map itself non-standard in some way? I ask because when connecting a Mac to the same amp by HDMI and setting audio output to 8 channels, the amp shows 7.1ch PCM, not 5.1ch as with the RP.

You may not have noticed my edit saying that the "stuck 7.1ch" issue only applies to the RP2, as this was added afterwards.

[popcornmix]

The map is standard. See the linked document there are two layouts for 7.1 audio.
I'm guessing your receiver has been set up to describe the speaker placement and it more closely matches the "19" layout. When given the "31" layout it presumably says I don't have FRC/FLC speakers and so drops (or downmixes) two channels.

I suspect if you played with the receiver settings you could claim the "31" layout and then you would see "7.1" with recent firmware and "5.1" with older firmware.

There might be an argument for changing the default for 7.1 to "19". We do use "19" for omxplayer and xbmc/kodi when in 7.1 mode as that seemed to match the channel layout kodi uses internally more closely (not exactly unfortunately - the final two channels are actually side left/side right which isn't an option though hdmi).

But if you are writing your own software that outputs multichanel audio then using the hdmi_channel_map gencmd is probably wise.

[tghewett]

Thank you, that works, including on the RP2.

Does the call to vc_gencmd() fork a subprocess to run vcgencmd in a shell or does it remain entirely within the running process?

[popcornmix]

The gencmd is a global setting, so you will have issues with multiple processes using different settings.
However these values are written to the hdmi hardware, so supporting multiple concurrent settings is never going to work.

[tghewett]

I'm interested really in the question of performance, i.e. does vc_gencmd() communicate directly with the hardware or just run vcgencmd as a sub process with the given string parameters.

[popcornmix]

vcgencmd is a RPC to the GPU (comparable to an openmax, mmal, or snd-bcm2835 operation). I'm assuming you are only calling it once per "playback" (e.g. song or video), so it's going to be negligible (e.g. sub millisecond).

[tghewett]

Sub millisecond is no problem at all.

As an aside, is there any scope for adapting the ALSA driver to support all the HDMI formats as indicated by the equipment EDID information? Is this information accessible to the driver for it to do this when equipment is connected? I'm not sure what normally happens on Linux with HDMI interfaces, I think I saw a PC one which always provided all permissible HDMI sample rates up to 192k regardless of equipment support. Macs always provide the formats supported by the equipment (and no more), sometimes limited to 96k, but certainly using the EDID info. This is just something I'm interested in doing myself if it is at all feasible.

[pelwell]

To be explicit, vcgencmd is a utility that calls vc_gencmd, not vice versa.

[popcornmix]

Unfortunately edid information is not always accurate.
We used to set defaults for passthrough support, number of channels and max sample rates from the EDID in xbmc, but have since let the user configure this manually as too many EDIDs were incorrect.

[tghewett]

As I have a workable solution I'll close the issue. I have no particular view on whether the default value for the channel map is right or wrong, though remain a little concerned that the same amp (with the same configuration) behaves fine with a Mac as described previously.

Thanks for the information about the EDID information.

[lbschenkel]

Sorry to bump this old issue, but is there any way to tell the firmware to use "19" for 7.1 without explicitly setting hdmi_channel_map? The problem with setting it explicitly is that it signals all output to be 7.1, even stereo, preventing a receiver from doing ProLogic II decoding, for example.

[popcornmix]

It might help if you explained what you were doing and how audio was being output.

[lbschenkel]

Sure. (I contacted you privately via e-mail yesterday about this, by the way.)

My intent is to send arbitrary audio files via HDMI to an amp/receiver using OMX (let's say via omxplayer). The reason for using OMX and not ALSA is because not all my audio is stereo: some is high-res, some multi-channel, etc. When I don't set any hdmi_channel_map, then the channels from the audio itself get transmitted via the stream and recognized as such by the receiver: 2.0->2.0, 5.1->5.1, etc. The problem is that in the default firmware behaviour, a 7.1 source is annotated with the "31" layout and my receiver does not like that: it displays the source as being 5.1 and just drops the other channels. I was hoping I could tell the firmware to annotate a 7.1 source with "17" instead, which does get interpreted correctly by my receiver as 7.1.

I can work around it by setting hdmi_channel_map to 0x13fac688, as previously discussed, however this has an unfortunate side effect: now all streams are annotated as being 7.1, and all the missing channels are padded with silence. The receiver now thinks this is a multi-channel source, even if the audio is actually stereo, and I cannot tell the receiver to upmix it or apply Dolby ProLogic II for example.

Now, if I could tell the firmware that 7.1 sources map to layout "17" instead of "31" (which was the old default behaviour, by the way) but without forcing any specific hdmi_channel_map, this would allow 2.0 audio to be recognized as by the receiver as 2.0, 5.1 as 5.1 and 7.1 as 7.1.

Does this clarify things?

[popcornmix]

Now, if I could tell the firmware that 7.1 sources map to layout "17" instead of "31" (which was the old default behaviour, by the way)

Can you clarify this? I don't believe anything has changed in this area in firmware for years - when do you believe this changed?

[lbschenkel]

I believe the default at some time in the past used to be "17" based on your message in this very issue:
#450 (comment)

P.S.: Sorry, I meant "19" when I wrote "17".

[popcornmix]

Okay, so years ago.
You say 17, but I suspect you mean 19 (0x13) which changed to 31 (0x1f) way back.
17 is 5.1 audio. 19 is 7.1 audio.

[lbschenkel]

Yes, I added a P.S. to my previous message. I meant "19" but I mistakenly wrote "17".

[popcornmix]

Have you tried kodi which does use hdmi_channel_map itself? I wonder if that behaves any differently.

[lbschenkel]

Not yet (and I will), but I have read the source code and I think I have a pretty good grasp of what it does. It looks at the channels of the input source and calculates what the hdmi_channel_map itself should look like, and sets that via vc_gencmd. Note that it uses 19, and not 31, for 7.1 channels:
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkPi.cpp#L170
https://github.com/xbmc/xbmc/blob/master/xbmc/cores/omxplayer/OMXAudio.cpp#L534

So no change from what I'm doing manually, it just does that automatically on playback (and when the source attributes change). I was hoping to find a solution that does not involve setting hdmi_channel_map due to my workflow. I don't plan to run Kodi, my end goal is to run MPD.

I am trying to make MPD output the audio via OMX (for the reasons I mentioned before). MPD does not have a OMX plugin at the moment (I'm considering contributing one at the end of this ordeal), but for now I have configured an ALSA device that pipes a wave file to a script that I wrote. The script uses GStreamer and omxhdmiaudiosink to play the input (my attempts to use omxplayer were not successful, it crashes when reading from stdin). I even have implemented logic to set hdmi_channel_map before playback based on the number of channels, just like Kodi does. However this does not work very well, because the ALSA device is not closed/reopened between files, so the script is not reinvoked and it can't set the a new map if the file being played now has a different number of channels.

I feel that trying to set the channel map at runtime introduces added complexity and fragility for something that is actually quite simple.

Ideally there could be a setting in config.txt that could allow selecting if 0x13 or 0x1F should be used by the firmware for indicating 7.1 channels when hdmi_channel_map is left at its default value of 0.

As an alternative, I could patch the firmware binary and replace 0x1F for 0x13 but I don't know where to look. Maybe you could help me out?