• 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!

N

Nisse10000

Member
Joined
Nov 14, 2022
Messages
31
Likes
15
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.
 
M

MCH

Major Contributor
Joined
Apr 10, 2021
Messages
2,699
Likes
2,336
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?
 
P

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
512
Likes
337
@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:
N

Nisse10000

Member
Joined
Nov 14, 2022
Messages
31
Likes
15
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
M

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
2,542
Likes
3,424
Location
Detroit, MI
I have a RPi5 and would like to play around with multichannel I2S, has there been any documentation on how to specifically do this? I see that @phofman referenced "rp1_i2s1_8ch", how would I apply this? I tried dtoverlay=rp1_i2s1_8ch in config.txt but it didn't seem to do the trick.

Michael
 
P

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
512
Likes
337
@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 .
 
P

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
512
Likes
337
Thanks! Somehow I have a problem viewing it, is it perhaps somehow private?

1706024076008.png
 
M

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
2,542
Likes
3,424
Location
Detroit, MI
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
 
P

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
512
Likes
337
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
 
G

gordoste

Member
Joined
Nov 19, 2023
Messages
34
Likes
32
@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
M

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
2,542
Likes
3,424
Location
Detroit, MI
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

S
Introduction to the SmartCross project
2 3
Replies
47
Views
8K
Old Iron
O
sweetchaos
Stop YouTube ads once and for all
3 4 5
Replies
92
Views
13K
dzerig
D
Top Bottom