alsa: multichannel PCM unsupported

Apparently this doesn't work yet. If I interpret this correctly, there is no kernel support for this yet. If I force ALSA to output more than 2 channels, none of them seem to arrive at the receiver either (unfortunately my receiver doesn't show the PCM format it gets).

I wonder what the 8 sub devices are for?

[popcornmix]

The 8 sub devices allow up to 8 processes to output audio simultaneously (and they get mixed together by GPU).

@julianscheel didn't you get multichannel alsa working? It may be as simple as rebuilding alsa driver to report 8 channels as the maximum.

Note that as far as userland is concerned, proper multichannel support will also need channel map support. But the alsa-lib on Raspbian is too old and does not support this API. It will require at least alsa-lib 1.0.27. (At least mpv and vlc rely on this.)

[julianscheel]

@popcornmix I did not try PCM multichannel so far. What I was doing is being able to use HDMI and analog output in parallel from different substreams (#847) - I never cleaned that code up to push it, though :( - I hope I'll find some time to do it.
Unfortunately I don't even have any >2 channel HDMI audio receiver, so I can't test that.

Is there anything I could help with? Shall I get the kernel sources, change the maximum channel count to 8, and see what happens?

[popcornmix]

Yes, please do. It might just work (apart from channel mapping). I did add support for multichannel to the firmware side a while back, but without anyone actively testing it, it wasn't enabled in kernel driver.

If you know how the channel mapping is meant to be passed from alsa userland -> alsa driver then I suspect I can support that (you can adjust channel mapping though a vcgencmd, but a standard way would be better).

Yes, please do. It might just work (apart from channel mapping). I did add support for multichannel to the firmware side a while back, but without anyone actively testing it, it wasn't enabled in kernel driver.

Will try later this week.

If you know how the channel mapping is meant to be passed from alsa userland -> alsa driver then I suspect I can support that (you can adjust channel mapping though a vcgencmd, but a standard way would be better).

Not yet, but maybe I can try to understand it.

Raising the max. channel count to 8 does work. I can output 6 channels, and they all arrive separately on the receiver. 8 channels also appears to work, except I can't test this properly because my receiver can do 5.1 only.

The only problem is that the ALSA API still doesn't report any channel maps, so this part still needs to be implemented. Haven't looked into it.

DTS-HD passthrough also almost works. I just had to raise the max. channel count to 8, and the max. samplerate to 192000 in the spdif device.

I've taken a small look. Channel maps are an additional control element (like the IEC958 switch), which is added with snd_pcm_add_chmap_ctls(). It seems there are basically two uses of this function:

• static list of channel maps (channel count uniquely identifies the channel layout, at least I guess)
• dynamic usage (callback fun)

The HDA HDMI driver (https://github.com/raspberrypi/linux/blob/rpi-3.18.y/sound/pci/hda/patch_hdmi.c#L2132) and the generic USB driver (https://github.com/raspberrypi/linux/blob/rpi-3.18.y/sound/usb/stream.c#L217) show somewhat how to use channel maps dynamically. They also set up a bunch of callbacks on the new control (get/set/tlv.c). I have no idea whether the API actually requires using callbacks to get dynamic behavior with multiple possible layouts per channel count. The callback stuff really looks pretty ugly (letting a driver manually set up really weird userspace data structures...?)

The HDA HDMI driver also lists a bunch of HDMI layouts, which might be useful:
https://github.com/raspberrypi/linux/blob/rpi-3.18.y/sound/pci/hda/patch_hdmi.c#L278
https://github.com/raspberrypi/linux/blob/rpi-3.18.y/sound/pci/hda/patch_hdmi.c#L776
(plus some more mapping code spread over the file)

Also, I don't know if HDMI can report the channel layouts supported by the device via EDID or so. Seems not?

On the RPI side, the only way I've found to set the channel layout is via sending the hdmi_channel_map command to the GCMD service. This is what xbmc does (uses vc_gencmd()). I haven't found anything related in vc_vchi_audioserv_defs.h. This sounds annoying, you'd have to create extra vchi connections and all. Maybe the firmware actually provides a better way? (The firmware is still closed source.)

If nobody else does, I might attempt to give it a try.

[popcornmix]

DTS-HD passthrough also almost works. I just had to raise the max. channel count to 8, and the max. samplerate to 192000 in the spdif device.

Are you saying you have had HD audio successfully play through HDMI on Pi? I can play 192kHz 8 channel PCM but I believe we drop samples at that rate. Any attempt at passthrough fails to lock on.
(Although there was a firmware tweak to the fifo settings a couple of weeks back that could have helped).

[popcornmix]

If nobody else does, I might attempt to give it a try.

If you can plumb in the support into kernel driver, then I can problably help on the firmware side.
I could add a new method to audioservice (e.g. VC_AUDIO_MSG_TYPE_CHANNELMAP) that takes a parameter like the vcgencmd hdmi_channel_map.

In theory the edid can be read (tvservice -d edid.dat) and the firmware does parse this so could provide it through other means. I believe that in general edid information is not considered reliable enough to used by default. We used to automatically choose passthrough options in Kodi based on edid, but have since made this purely a user selectable option as there are just too many bad edids out there (Kodi doesn't trust the edid on windows/linux platforms either).

Are you saying you have had HD audio successfully play through HDMI on Pi? I can play 192kHz 8 channel PCM but I believe we drop samples at that rate.

I can try again and pay attention to the quality.

Any attempt at passthrough fails to lock on.

The receiver didn't seem to complain when playing DTS-HD.

If you can plumb in the support into kernel driver,

I can try it. No guarantee for success. It'd be my first time hacking on a Linux driver.

then I can problably help on the firmware side.
I could add a new method to audioservice (e.g. VC_AUDIO_MSG_TYPE_CHANNELMAP) that takes a parameter like the vcgencmd hdmi_channel_map.

Sounds ideal.

In theory the edid can be read (tvservice -d edid.dat) and the firmware does parse this so could provide it through other means. I believe that in general edid information is not considered reliable enough to used by default. We used to automatically choose passthrough options in Kodi based on edid, but have since made this purely a user selectable option as there are just too many bad edids out there (Kodi doesn't trust the edid on windows/linux platforms either).

Then it's probably fine not to care about this aspect.

[popcornmix]

@wm4 Let me know how you were playing the file (perhaps point at the file you used and commands used to play it) and I'll see if I get the same results here (I've got a Yahama receiver at work and an Onkyo at home).

Before the recent fifo tweaks we found some receivers played stereo 192kHz audio perfectly, but some suffered from dropouts. You might imagine either we are outputting valid data or we weren't but it seems the real answer is more complicated.

What receiver are you using? It possibly is more tolerant than mine.

What receiver are you using?

Pioneer VSX-329-K

Also I haven't tested anything with 192khz PCM, only DTS-HD (which pretends 192khz via spdif to reach the required bitrate). The rest I'll test later.

I tried 192Khz PCM. Yes, it seems to run into problems here. I tried to play a 192khz 8ch float wav file, and it seems mpv isn't fast enough to push the data to ALSA. It also uses too much CPU. (Probably too much memcpy.) aplay seems to work fine though. When using s16 instead of float it's better (alsalib doesn't need to convert anymore), then aplay barely uses CPU and I can't recognize any dropouts.

I actually can't get DTS-HD to work. The receiver displays the expected text on the OSD (which indicates DTA MA), but there's only silence, and then some clicks. I'm not sure what happens. I've tried to make a wav to get aplay to stream DTS-HD to the receiver, but this didn't work. (I guess the audio got mangled somewhere along the way, or I didn't set the mixer to 0db correctly.) I'm not sure if it actually worked when I tested it last time, or if I only looked at the receiver display.

[popcornmix]

I've never got DTS-HD passthrough working. I'd be very interested if you do actually get audio out, but I suspect it may not be possible.
Whilst an 8channel 192kHz wav file can almost be played, I suspect if you listen carefully to a sine wave you will hear the odd glitch.
The hardware wasn't really designed for this data rate. I believe 192kHz stereo is perfect and 48kHz 8 channel is perfect, but 192kHz 8 channel does drop the odd sample.