• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Multichannel audio on a Pi will get a whole lot easier and cheaper!

oomzay said:
@Nisse10000

As best I understand the HDMI standard, the audio-channel-to-speaker-position mapping is meant to be communicated to the receiver via the CA code as specified in CEA-861-D.

Is my understanding correct?

If so, then the speaker-test mapping you copied does not appear to match any of the valid mappings!

So after a week or more of spare-time googling what seems to be a very fundamental aspect of channel mapping this still does not add up at all for me :(

Key question (I think): How is the transmitted HDMI CA code determined?

Update:
At last I found a thread to pull on... Its the 2008 Takashi Iwai patch that literally just guesses what mapping is intended based on the number of channels!!! Hopefully this is not state-of-the-art solution any more! I'll see where this leads me when I next get some time... (The reason this matters so much in this context is that I can't develop a robust regression test for the catastrophic channel swapping problem without being clear what the mapping is actually meant to be! - and without that I would be very nervous of using linux for any multichannel audio application - however 'easy' and 'cheap').
Click to expand...
I don't think that the key question is the negotiation since I get different reshuffle results, ie it is not a switch between two different mapping. It seems to be a bit random though left channel seems to ber missing most of the time.
 
Nisse10000 said:
For me, it seem like only the vc4 driver exhibit the shuffling of channels. At least it is a lot less frequent. I've been using it for a about day now without needing to restart CamillaDSP. With the vc4 driver just a few switches between pause and running will reshuffle.

And I do not know what the iec958 really does. It accepts 32 bit and soud is working but the receiver should not allow for that. So some re-sampling must be present.
Click to expand...
Could you please force buffer underruns with a very short buffer and see what happens?
 
@Nisse10000 : Thanks, that's a very important finding, IMO. Please check the xruns as @MCH suggested.

Since the VC4 (KMS) and RPi GPU firmware (FKMS) are closed-source, perhaps the next step should be reporting to the RPi devs. Only they would know the difference between the two drivers at xrun/pause handling, from the actual HDMI controller point of view. I would tend to believe it's only a matter of some register writes at snd prepare.
Nisse10000 said:
I do not know what the iec958 really does. It accepts 32 bit and soud is working but the receiver should not allow for that.
Click to expand...
IIUC the iec958 format is the bit format used in SPDIF and HDMI audio. This is the conversion method from int32 to the 32bits of IEC958 https://github.com/alsa-project/als...b609d0e50316a68/src/pcm/pcm_iec958.c#L92-L133. Only 24 MSBs are used from 32 bits samples.
Nisse10000 said:
So some re-sampling must be present.
Click to expand...
Only bit truncation 32 -> 24.
 
Last edited:
I no longer get channel remapping using fkms. I’ve set the silent timeout to a few seconds and then repeated a few sounds every 10 seconds or so. No remapping. The feel good is a bit lower with 16 bits but much better than the remapping.
 
  • Like
Reactions: MCH
@mdsimon2 : That block name rp1_i2s1_8ch was just an example. What needs to be changed is this definition of GPIOs https://github.com/raspberrypi/linux/blob/rpi-6.7.y/arch/arm/boot/dts/broadcom/rp1.dtsi#L666-L676 - the four pins need to be replaced with all I2S pins (as listed in https://forums.raspberrypi.com/viewtopic.php?t=359494#p2156536 - UNTESTED!).

IMO the safest way to start would be changing the pins list directly in the kernel source (keeping the block name), and recompiling the kernel which would generate updated device tree configs too.

After having tested the change to work, the fight to a working overlay can be undertaken. IME overlays are quite difficult to do correctly and hard to troubleshoot. On regular ARM I have to watch uboot verbose output via serial port (as overlays are applied by the boot manager before kernel boots). In RPi (in which the GPU= firmware bootloads linux on the ARM cores) that would be some debugging output of the RPi firmware (probably using some tool, maybe serial port too).

Another advantage to recompiling the kernel would be the IMO non-zero likelihood of having to modify the driver itself (at least inserting some debug messages). My question about initial max channels read from the DWC I2S IP core configuration https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/dwc/dwc-i2s.c#L719-L720 was basically never answered https://forums.raspberrypi.com/viewtopic.php?t=356922&start=425#p2143889 . But maybe the max channels value is already configured to 8 in RP1 DWC I2S IP (so many abbrevs :) ). That should be listed e.g. in aplay --dump-hw-params of the I2S device. But you have to make sure all ASoC components accept the 8 channels (DAI, codec, board, etc.) and do not limit them. It will depend what ASoC platform config you will use - I would recommend the https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master / https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Slave which uses simple-audio-card and spdif ASoC codecs that have no channel limits https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/codecs/spdif_receiver.c#L52-L53 , https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/codecs/spdif_transmitter.c#L52-L53 .
 
Thanks! Somehow I have a problem viewing it, is it perhaps somehow private?

1706024076008.png
 
phofman said:
@mdsimon2 : That block name rp1_i2s1_8ch was just an example. What needs to be changed is this definition of GPIOs https://github.com/raspberrypi/linux/blob/rpi-6.7.y/arch/arm/boot/dts/broadcom/rp1.dtsi#L666-L676 - the four pins need to be replaced with all I2S pins (as listed in https://forums.raspberrypi.com/viewtopic.php?t=359494#p2156536 - UNTESTED!).

IMO the safest way to start would be changing the pins list directly in the kernel source (keeping the block name), and recompiling the kernel which would generate updated device tree configs too.

After having tested the change to work, the fight to a working overlay can be undertaken. IME overlays are quite difficult to do correctly and hard to troubleshoot. On regular ARM I have to watch uboot verbose output via serial port (as overlays are applied by the boot manager before kernel boots). In RPi (in which the GPU= firmware bootloads linux on the ARM cores) that would be some debugging output of the RPi firmware (probably using some tool, maybe serial port too).

Another advantage to recompiling the kernel would be the IMO non-zero likelihood of having to modify the driver itself (at least inserting some debug messages). My question about initial max channels read from the DWC I2S IP core configuration https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/dwc/dwc-i2s.c#L719-L720 was basically never answered https://forums.raspberrypi.com/viewtopic.php?t=356922&start=425#p2143889 . But maybe the max channels value is already configured to 8 in RP1 DWC I2S IP (so many abbrevs :) ). That should be listed e.g. in aplay --dump-hw-params of the I2S device. But you have to make sure all ASoC components accept the 8 channels (DAI, codec, board, etc.) and do not limit them. It will depend what ASoC platform config you will use - I would recommend the https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master / https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Slave which uses simple-audio-card and spdif ASoC codecs that have no channel limits https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/codecs/spdif_receiver.c#L52-L53 , https://github.com/raspberrypi/linux/blob/rpi-6.7.y/sound/soc/codecs/spdif_transmitter.c#L52-L53 .
Click to expand...

Thanks! Just compiled kernel 6.7 with all i2s pins specified in rp1_i2s0_18_21 and rp1_i2s1_18_21.

You mention testing the change to work, what does this entail?

I installed RaspberryPi_I2S_Master and here is what I get from --dump-hw-params.

Code: 
michaeldsimon@raspberrypi5:/proc/asound/i2smaster/pcm0p/sub0 $ aplay -D hw:i2smaster --dump-hw-params /dev/zero
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:i2smaster":
--------------------
ACCESS:  MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT:  S16_LE S24_LE S32_LE
SUBFORMAT:  STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 512]
CHANNELS: [2 16]
RATE: [8000 192000]
PERIOD_TIME: (10 128000]
PERIOD_SIZE: [2 1024]
PERIOD_BYTES: [128 4096]
PERIODS: [2 65536]
BUFFER_TIME: (20 16384000]
BUFFER_SIZE: [4 131072]
BUFFER_BYTES: [128 524288]
TICK_TIME: ALL
--------------------
aplay: set_params:1352: Sample format non available
Available formats:
- S16_LE
- S24_LE
- S32_LE

When I have some more time this evening I'll try to do some actual audio testing. My plan is to use an IanCanada McFIFO / McDualXO which will be handle 8 channel I2S input, not require a master clock and provides 8 channel I2S output with 4x MCLK, BLCK, LRCLK in to 4X WM8804 I2S to AES boards.

To be honest I am more interested in potential 8 channel I2S input as I have a HDMI to 8 channel I2S extractor and this seems like a very bare bones way of getting 7.1 PCM in to a RPi for DSP purposes. But I also figured that 8 channel I2S output will be easier to test / troubleshoot to start.

Michael
 
Is that aplay dump from the modified kernel?

IIUC the hard-coded config for the DWC I2S IP is 16 channels, that looks good.

You can just play 8ch sox and watch the DOUT pins. Or make a hw loopback - connect DOUT to DIN pins and play/capture. sox -V shows levelmeter of the captured stream, simplifies testing. For bit-perfection I like playing a single sine in sox and checking captured spectrogram in another sox - all 8 channels at once. Every issue is cleanly visible. You can check for 32bit perfection with spectrogram -w kaiser -z 180
 
@mdsimon2 I'll be buying an RPi5 as soon as someone actually verifies multi-channel I2S output works, so I'm very interested in hearing what you find.
@Nisse10000 You already got a response!
 
  • Like
Reactions: MCH
Yes, aplay dump from modified 6.7 kernel.

Did some preliminary testing. I used CamillaDSP with a hifime UR23 as capture device and i2smaster as playback device, just routing capture channel 0 to playback channels 0, 2, 4, 6 and capture channel 1 to playback channels 1, 3, 5, 7.

I was just probing pins with a scope, but BCLK and LRCLK behave as expected and I get data on all 4 outputs when playing a test tone and no data when I mute channels in CamillaDSP. So far very promising.

Michael
 
You must log in or register to reply here.

Similar threads

G
  • Locked
Is there even a tiny bit of truth in all the marketing voodoo that audio cable manufacturers say? Or is it all BS?
10 11 12
Replies
235
Views
22K
Jimbob54
Jimbob54
Back
Top Bottom