alsa: HDMI passthrough support

[julianscheel]

It would be nice to be able to use the snd_bcm2835 alsa driver not only for PCM playback but also for passthrough of encoded audio formats like AC3 through the HDMI port.

[popcornmix]

Do you have any references to what the alsa driver should do to support this?

Technically you can do it with spdif encapsulated AC3 or DTS sent as stereo PCM:
raspberrypi/firmware#183

You should add config options "no_hdmi_resample=1" and "hdmi_stream_channels=1" to config.txt to ensure data gets through uncorrupted.

[julianscheel]

Thanks for the notes. From the alsa side there's nothing special. A 2 chanel S16_LE device should be just fine. So likely it will just work with these parameters set.
I will test and report.
Would it be possible to set these parameters at runtime instead of config.txt? Sounds like they could harm normal PCM playback in some circumstance (ie low sampling rates)

[popcornmix]

Actually latest (rpi-update) firmware has no_hdmi_resample=1 as a default, and

vcgencmd hdmi_stream_channels 1

will enable hdmi_stream_channels at runtime (0 to disable).

hdmi_stream_channels determines if the AV infoframe reports the actual number of channels (i.e. 2) or 0 (which means refer to stream).

I did try using "refer to stream" in a build a while back which all the hdmi devices we have here worked correctly for either stereo PCM or passthrough formats.
Unfortunately there were a few reports of PCM stereo not working so it needs to be something switchable.

I'm trying to find if there is a way of indictating to alsa driver when passthrough is in use, so the switch can be done. XBMC ALSA sink (for other platforms) uses "AES0-0x06" for passthrough and AES0=0x04" for non-passthrough formats - I think appended to the device name that is opened, but I didn't find a description of what exactly this does.

[julianscheel]

The AES0 suffix to the device name can indeed be used to detect non-audio streams. When it's set to 0x06 the bit IEC958_AES0_NONAUDIO (see asounddef.h) is set. Using IEC958_AES0_NONAUDIO as indicator should be a good choice. A quick grep over the kernel shows that some drivers handle it like that.

[popcornmix]

I can't see where the AES0=0x60 is parsed in the (any) ALSA kernel driver.
Yes, in theory I could parse the spdif stream and extract the IEC958_AES0_NONAUDIO bit, but that would be an expensive operation compared to parsing the ALSA device name.

[julianscheel]

Afaict the flags are parsed in alsa-lib when you open the device (see src/conf/pcm/iec958.conf or hdmi.conf). And are applied to the appropriate control, which the driver has to expose. See http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch10s03.html

[julianscheel]

I finally was able to do some more testing and got it working with VLC. Had to remove the arguments that VLC adds to the device (the AES ones). So adding a dedicated alsa device iec958 or hdmi which understands these sounds like a good idea.
If you instruct me how to set the no_hdmi_resample option out of the kernel instead of through vcgencmd I can try extending the alsa driver.

[popcornmix]

Latest firmware has no_hdmi_resample as default (for alsa). It will only resample if output sample rate is not supported, but using 44.1kHz or 48kHz should be fine.

The only thing you may want to set is hdmi_stream_channels=1 (which can be done with a vcgencmd). Actually many receivers don't care and passthrough may well work with or without this setting.

I can easily add this option as a flag when opening the alsa driver. If you find the right way to name the driver and extract the AES flags so it looks like a passthrough capable sound card that would be good.

A suggestion for how to flag passthrough it is to use channels=0 in the VC_AUDIO_CONFIG_T. structure. That will be interpreted as two channels in most uses, but will signal 0 (refer to stream header) for number of channels in the audio infoframe.

If that sounds okay I'll add that option to the next firmware update.

[julianscheel]

Ok, I've got this coded together roughly already. Using channels=0 sounds ok. Is there a possibility to set any of the further iec958 status flags to the chip? Like consumer/professional mode or emphasis settings?
Right now I only care about the NONAUDIO flag which I would use to set channels=0.

As of now I created a dedicated subdevice hw:0,1 for this, probably we could also skip this and configure iec958 to use hw:0,0 as well. It seems that basically all cards seem to make up a dedicated device for spdif, even if it's actually the same device.

[popcornmix]

If you make any useful iec958 status bits available in the driver (e.g. where config structure is filled in) I can look at plumbing it through.

[julianscheel]

The driver allows the userspace to set AES0...AES3 as parameters. Each one is a byte. Possible values are defined in asoundef.h - I could pass through any of these. Although I doubt it makes sense.
NONAUDIO is important to distinguish PCM vs encoded formats, so this one is handled anyway. Most userspace applications seem to set EMPHASIS on AES0. AES3 can be used to signal FS, don't know if it makes sense to pass that through?
Besides I don't know if any of these flags are really needed in our use-cases. What do you think?

[popcornmix]

I can't see any of these being important apart from the NONAUDIO one.
The 192 status bits will be set to sensible defaults by GPU. Looks like we set bits:
1: when passthrough
2: no copyright
24:27: samplerate
32:35: 24-bit samples
36:39: samplerate
all others are clear.

[julianscheel]

What about the consumer/professional flag? Does it make any sense for us to set it. Otherwise I will limit the options to just allow userspace to set NONAUDIO and ignore the rest.

I just pushed my wip code: julianscheel@b0d3971
Also rebased it onto the rpi-3.10.y branch, just haven't testet it with 3.10, but should work. Additionally to the updated driver you will need a bcm2835.conf (be aware I renamed the driver to just bcm2835 to avoid a long filename with spaces) into /usr/sshare/alsa/cards.
See here: https://gist.github.com/julianscheel/9094131

I have tested this with vlc (--spdif option and --aout alsa). Works very well so far.

[popcornmix]

Bit 0 is set to 0 (consumer). I'm not sure what difference professional makes.

I'll test your patch. In theory I should be able to make xbmc output passthrough audio through it and can use that for testing the channels=0 code path.

[popcornmix]

Out of interest if driving multichannel PCM through HDMI (without passthrough) how is the speaker mapping configured?
i.e. can the application request 2.1 (left, right, lfe) and 3.0 (left, right, centre)?
Any interest in getting this working?