alsa: multichannel PCM unsupported

[ghost]

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.

[ghost]

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.

[ghost]

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).

[ghost]

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.

[ghost]

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.

[ghost]

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).

[ghost]

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.

[ghost]

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.

[ghost]

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.

[ghost]

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.

Other than the receiver indicating DTS-MA, no. So if you're right and 192khz @ 8ch subtly drops or changes samples, then it could be that the receiver gets the correct DTS headers, but is then unable to decode the DTS frame correctly. The result is silence, or the occasional clicks I was hearing - but the receiver won't try to interpret it as PCM, because the next valid DTS header and/or SPDIF frame is not far. Makes sense to me.

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.

My hearing isn't particularly good. Any tips how to generate the sine wave? (Or rather, what frequency would be good.)

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.

Does this restriction definitely apply to kodi's OMX output as well? (It certainly should, since it's the same hw, I'm just asking for definite confirmation so I don't need to possibly pursue an OMX solution.)

Maybe there's no other choice but to restrict output this way. I guess I'll need to find out how to do this with the ALSA kernel API. What is the actual hw limit based on? On a maximum bit rate?

[popcornmix]

/opt/vc/src/hello_pi/hello_audio will generate a sine wave using openmax and you can specify channels and samplerate on command line.

The limit is on the GPU peripheral (I believe the audio fifo in the hdmi block), so omx and alsa will behave the same.

Actually just checking but we currently limit channels_samplerate to 8_96000.
If you output more than this the GPU will resample then audio down to below this limit (e.g. 8 channel 192kHz sudio will be resampled to 8 channel 96kHz).
You can adjust this with hdmi_samples_limit in config.txt. E.g.
hdmi_samples_limit=1536000
should bypass this limit. By default it is 768000.
So I believe that would have made DTS-HD passthrough impossible. Might be worth trying again with the increased limit (but I'd be surprised if it works).

[ghost]

I tried with hdmi_samples_limit=1536000 in config.txt. It doesn't seem to help too much. DTS-HD is broken in the same way (although, if it really had been resampled with default settings, I can't explain how the DTS header made it to the receiver). hello_audio 1 8 192000 plays a tinnitus-inducing sound, but seems to be ok. I can't make out any distortions.

Well, 8 channels at 96khz is still great, and having yet another reason to discourage DTS passthrough is actually a feature in my book. (I just hope libdcadec is fast enough.)

[popcornmix]

We support libdcadec in kodi and it's fine on Pi2.
On Pi1 it's a bit tight - about half the speed of ffmpeg's dca decoder.

[popcornmix]

Your receiver probably has an info/display mode that shows the samplerate and number of channels. That should confirm if 192kHz is being output or if it's being resampled down.
Note: If edid doesn't report support for a frequency we will resample down.
Check with tvservice -a

[ghost]

Unfortunately the receiver doesn't seem to display this anywhere.

I'll check with tvservice tomorrow.

[amtssp]

Sorry for asking the obivious question.
Are you sure that alsa does not change output level?
It should be set to 100% otherwise it Will not output bit perfect.

[ghost]

tvservice -a:

     PCM supported: Max channels: 8, Max samplerate: 192kHz, Max samplesize 24 bits.
     AC3 supported: Max channels: 6, Max samplerate:  48kHz, Max rate  640 kb/s.
     DTS supported: Max channels: 7, Max samplerate:  48kHz, Max rate 1536 kb/s.
  DTS_HD supported: Max channels: 8, Max samplerate: 192kHz, Max rate    8 kb/s.

(On a side note, does RPI support 24 bit sample output?)

@amtssp: normal DTS output works just fine.

[popcornmix]

Yes, 24-bit samples are supported by hardware.

[pssc]

But this is not enabled in the alsa driver... (~3.18)
sound/arm/bcm2835-pcm.c

 static struct snd_pcm_hardware snd_bcm2835_playback_hw = {
        .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
                 SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
-       .formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
-       .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
+       .formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
+       .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_192000,
        .rate_min = 8000,
-       .rate_max = 48000,
+       .rate_max = 192000,

[ghost]

Didn't try to enable S24 yet.

For 192khz output, I added something to my private branch which restricts it to channel counts which the RPI supposedly can handle without dropouts.

[pssc]

yeah I haven’t been able to test this yet on my private build due to device tree issues, but 24bit 96k would be of use event at 2 channel this would be well within the pi's caps?

[popcornmix]

@wm4 you shouldn't have to restrict channels x samplerate as the firmware should downsample what it thinks is unsupported anyway.

In theory 192kHz, 8 channel and 24bit (or 32bit if useful with GPU discards 8 lsb) should work but are untested. If you confirm what does work, we'll enable in ALSA driver. If you point out what doesn't work, we can probably support it in firmware.

[ghost]

@wm4 you shouldn't have to restrict channels x samplerate as the firmware should downsample what it thinks is unsupported anyway.

I don't know, personally I'd prefer if it didn't resample to a lower samplerate. Actually, maybe it shouldn't resample at all. The downside is that resampling is almost certainly more efficient on the GPU, even though it uses an unknown algorithm with unknown implementation quality.

[popcornmix]

I believe the gpu resampling will be higher quality than anything done on the arm.
And the arm is not going to handle resampling 8 channel 192kHz audio on a Pi1 (and I'm not sure about Pi2).

[ghost]

I updated my branch: https://github.com/wm4/linux/tree/multichannel_pcm

Unfortunately, I found that it adds heavy artifacts at the channel counts 3, 5, 6, and 7. Counts 1, 2, 4, 8 work. This also happens when merely extending the number of channels in the kernel driver, so my code is not the cause. Nothing else seems to use this API ("AUDS" vchi server), and it's completely undocumented, so I can't even guess. What's wrong with it?

[ghost]

Ping.

[ghost]

Couldn't find a cause or solution for the noise and the wrong quad layout. I pushed a hack that removes the noise by always forcing 8 channels for multichannel PCM. Still doesn't fix the quad layout though.

Is anyone still interested in this, or is everyone sore because I insulted the firmware a bit?

[julianscheel]

@wm4 You should consider that people have other things to do as well. Just give everyone a little bit of time and keep the discussion on a technical level. I'm sure everyone is trying its best to address all issues which are reported, but sometimes it's also a matter of time and priorities how long it takes.

Just my 2 cents...

[popcornmix]

Internally the audio engine on gpu only supports powers-of-two numbers of channels (i.e. 1, 2, 4, 8).
I have added some support for other numbers of channels through openmax (effectively by expanding the buffer provided to the next power of two). A possible feature request could add similar support to the alsa audio service. This could of course also be handled in the alsa driver on the arm side, but the gpu may be able to handle it more efficiently.

[ghost]

Internally the audio engine on gpu only supports powers-of-two numbers of channels (i.e. 1, 2, 4, 8).

OK, so there's a good explanation.

I have added some support for other numbers of channels through openmax (effectively by expanding the buffer provided to the next power of two). A possible feature request could add similar support to the alsa audio service. This could of course also be handled in the alsa driver on the arm side, but the gpu may be able to handle it more efficiently.

Yes, and currently my changes attempt to handle it this way. My original code tried to "pack" all real channels, and the audio service code was supposed to add the padding channels, which are apparently required by HDMI. This didn't work well, so I just changed all padding channels to SNDRV_CHMAP_NA, which basically forces userspace to insert these padding channels. But I'm still having problems, like the aforementioned issue with quad layouts.

Currently, I pad all layouts with more than 2 channels to 8 channels. (4 would also be possible, but I tried to be on the safe side.) The unused channels are filled with silence. Userspace still has to write them, but knows which channels are silent thanks to the channel layout reported by the kernel.

So for playing quad, userspace queries the set of supported channel maps, finds one that looks like quad. Currently, this is FL FR NA NA RL RR NA NA (formatted by snd_pcm_chmap_print()). It has 8 channels, so userspace requests 8 channels. Then it sets the layout.

The kernel eventually sends the command hdmi_channel_map 0x08fac688 to videocore, and reinitializes the audio service with 8 channels. I reversed-engineered (well what else would you call it) the hdmi_channel_map command from the Kodi code, and it should mean: set Audio InfoFrame Data Byte 4 to 0x08, which is - - RR RL - - FR FL (this is backwards for some reason, because of the way the table is organized). This matches the ALSA channel map from above. The rest (0xfac688) just assigns each of the 8 channels to itself (3 bits per channel).

The actual sequence of hdmi_channel_map commands and initializing the audio service is actually more complicated - I assume due to ALSA being ALSA. The following log is what happens when starting playback:

[ 1666.831489] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x00fac688
[ 1666.831633] bcm2835_audio_set_params:694 channels: 8
[ 1666.831787] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x00fac688
[ 1666.832694] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x08fac688
[ 1667.725072] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x08fac688
[ 1667.725225] bcm2835_audio_set_params:694 channels: 8
[ 1667.725418] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x08fac688
[ 1667.731650] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x08fac688
[ 1667.731792] bcm2835_audio_set_params:694 channels: 8
[ 1667.731965] bcm2835_audio_set_ctls_chan:588 run vc command: hdmi_channel_map 0x08fac688

[ghost]

Ping.

What do I need to send to the firmware?

[ghost]

So I got a report that the analogue output is playing distorted with more than 2 channels. I can reproduce this even with hello_audio.bin.

Meanwhile multichannel audio still sometimes doesn't work correctly (same problem as almost 3 weeks ago), and it's like the firmware either doesn't send the CEA channel layout data byte correctly, or the mysterious hdmi_channel_map works differently from what I expected. (Note that I can't test with kodi due to lack of an USB keyboard/mouse. So I don't know if there's just a difference in how my patch uses this command.)

Currently it seems like the only way to get actually working multichannel is via AC3 passthrough/transcoding.

[popcornmix]

If you have network then kodi can be driven from a smartphone app.
omxplayer supports multichannel.
These both use openmax rather than alsa for audio output. However most of the GPU side code is common so it may still be relevant. You can check the value of hdmi_channel_map when running to compare it with yours.

[popcornmix]

Analogue doesn't support multichannel, and there is no automatic downmixing, so I'd expect a bad result. Ideally the alsa driver would only allow 2 channels when analogue is enabled, but I suspect that may not be straightforward if you want more channels for HDMI.

Automatic downmixing for analogue is not impossible, but would be a feature request rather than a bug fix as it's not something trivial to support.

[ghost]

If you have network then kodi can be driven from a smartphone app.

I don't have a smartphone.

These both use openmax rather than alsa for audio output.

I know. But the interesting OMX parts are apparently implemented in the firmware, rather than calling the same services the ALSA kernel driver uses. So unless we use OMX in the kernel, there's little overlap.

Ideally the alsa driver would only allow 2 channels when analogue is enabled, but I suspect that may not be straightforward if you want more channels for HDMI.

Yes, I've added a hack for it. If the user explicitly sets the ALSA controls to route audio to analogue, then the next ALSA stream opened will report only the stereo channel layout. (Maybe it could also hard-limit the number of channels, but sane applications will not try to open more than 2 channels for stereo.)

[bigmacattack]

What is the status on this? I'd really like to take advantage of multi-channel PCM output via HDMI using ALSA.

[ghost]

There is a pull request which implements it. I guess I'll get to updating it once I'm back from vacation.

[keylimesoda]

It looks like @wm4 has closed his private repo. Changes can now be reviewed (along with further discussion) on the pull request here:

#1166

[ghost]

It looks like @wm4 has closed his private repo.

Huh? It's still there.

[keylimesoda]

Old links were 404 on me. Looks like you changed the name slightly.

Is this the correct link now?

https://github.com/wm4/linux/tree/multichannel_pcm2

[ghost]

Right, I deleted the old branch.

Yes, that branch is the current PR.

[Ruffio]

@wm4 has your issue been resolved? If so, please close this issue. Thanks.

[ghost]

The PR is still pending.

[keylimesoda]

@Ruffio PR is here: #1257

[clivem]

The patches in #1257 were applied then reverted. They caused more problems than they solved.......

[shalnoff]

is it still pending?

[piques]

Hi, does the A52 alsa plugin work on the RPi3?

Any help is appreciated. Sorry for being off-topic, I thought the folks here have RPis and multi-channel and this would be a good place to ask. I can create a new issue and I also posted about this here. Thank you.

[TheBigW]

no it seems it doesn't :(. I just tested on my fresh updated raspbian installation with speaker-test for 6 channels. It abords with an error:

ALSA lib conf.c:4705:(snd_config_expand) Unknown parameters {AES0 0x6 AES1 0x82 AES2 0x0 AES3 0x2 CARD 0}
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM iec958:{AES0 0x6 AES1 0x82 AES2 0x0 AES3 0x2 CARD 0}

I would really need this for a room correction setup with osmc using brutefir ... now I probably need to consider different hardware even though the raspi is great for htpc use. I still use it for music playback.

[JamesH65]

Seems to still be valid - @popcornmix Any thoughts?

[MarcoRavich]

Hi everyone, dunno if this can help to solve the problem, but seems this guy done some kernel hacks to get multichannel work: https://www.instructables.com/Raspberry-Pi-Music-Server-With-Built-in-Crossover-/

His GH here: https://github.com/jrubinstein/raspiDSP

Hope that helps/inspires !