RPi 5 quad-lane I2S

[diyelectromusic]

Apparently the RPi 5 supports 4 lanes of I2S output. Would it be possible to expand the I2S support from 2 channels to 8?

The hifiberry-dac8x-overlay.dts appears to show how this could work for a quad-PCM5102A configuration.

It appears to share the clock signals, and then have independent data pins, but I must admit that part isn't totally clear to me.

Kevin

[rsta2]

It's on my TODO list now. Should be able to test this with a single PCM5102A by switching the data input to the different GPIOs. Yes, I assume the clock signals are shared.

[rsta2]

The quad-lane I2S support is on the develop branch. You can test it using test/sound-controller after applying this small patch:

diff --git a/test/sound-controller/config.h b/test/sound-controller/config.h
index 366c739..619089a 100644
--- a/test/sound-controller/config.h
+++ b/test/sound-controller/config.h
@@ -23,7 +23,7 @@
 #define SAMPLE_RATE    48000           // overall system clock
 
 #define WRITE_FORMAT   1               // 0: 8-bit unsigned, 1: 16-bit signed, 2: 24-bit signed
-#define WRITE_CHANNELS 2               // 1: Mono, 2: Stereo, max. 32
+#define WRITE_CHANNELS 8               // 1: Mono, 2: Stereo, max. 32
 
 #define VOLUME         0.5             // [0.0, 1.0]
 
diff --git a/test/sound-controller/soundshell.cpp b/test/sound-controller/soundshell.cpp
index 410c394..5b4295a 100644
--- a/test/sound-controller/soundshell.cpp
+++ b/test/sound-controller/soundshell.cpp
@@ -391,7 +391,7 @@ boolean CSoundShell::Start (void)
                                                        SAMPLE_RATE, CHUNK_SIZE,
                                                        nClockMode == ClockModeSlave,
                                                        m_pI2CMaster, nI2CSlaveAddress,
-                                                       CI2SSoundBaseDevice::DeviceModeTXOnly);
+                                                       CI2SSoundBaseDevice::DeviceModeTXOnly, 8);
                        m_bI2SDevice[ModeOutput] = TRUE;
                        break;
 

Enter in the test shell:

start sndi2s o m
osc sine 1000 CHAN

CHAN is the channel number (1 .. 8). This will play a sinus tone of the given frequency on the given channel. Enter help for more options.

[diyelectromusic]

I'm trying to get this to work with four PCM5102s, but I don't seem to be getting any differentiation between the channels. Writing to (say) channel 1 seems to change all channels.

I've tried expanding the set of possible channels in soundshell.cpp as follows:

const CSoundShell::TStringMapping CSoundShell::s_ChannelMap[] =
{
        {"all",         CSoundController::ChannelAll},
        {"l",           CSoundController::ChannelLeft},
        {"r",           CSoundController::ChannelRight},
        {"1",           CSoundController::Channel1},
        {"2",           CSoundController::Channel2},
        {"3",           CSoundController::Channel3},
        {"4",           CSoundController::Channel4},
        {"5",           CSoundController::Channel5},
        {"6",           CSoundController::Channel6},
        {"7",           CSoundController::Channel7},
        {"8",           CSoundController::Channel8},
        {0,             CSoundController::ChannelUnknown}
};

As it appeared that any unrecognised channel (there was initially only "l" and "r") seemed to set all channels anyway, but I've still not had any luck.

Update: Ok - ignore that, I've just found ConvertNumber ;)

Nope - not sure what is going on. It does seem to set the waveform/frequency for the VCO, but as I say I don't seem to get a mapping of the channel onto the different modules :/

Any ideas?

I know the four modules can world independently as I'm using the same setup as this: https://diyelectromusic.wordpress.com/2024/05/27/rpi-5-quad-stereo-sound-with-pcm5102a/

Kevin

Kevin

[rsta2]

Unfortunately not. I tested it again here, and it works. I have only one PCM5102A board, but I can connect its DATA line to GPIO21, 23, 25 and 27 one after another and can modify the audio signal using osc for the respective channels and can listen to it. I did:

• Checkout the develop branch
• Modified the two lines in the sound-controller test source
• Build and started the test
• Entered:

start sndi2s o m
osc noise
osc sine 1000 1
osc sine 1000 2
osc sine 1000 3
osc sine 1000 4
osc sine 1000 5
osc sine 1000 6
osc sine 1000 7
osc sine 1000 8

The osc noise sends noise to all channels. Afterwards osc sine 1000 1 sends a 1000 Hz sinus to channel 1 and so on. The channels are numbered from 1 to 8 here. osc sine 1000 0 switches all channels at once.

Rene

[diyelectromusic]

So you definitely only get a change on the required channel and not all the others? So when your PCM5102 is on channel 3/4, the osc command for channel 1 or 2 has no effect? Hmm...

I think part of the problem is that on start sndi2s it plays on all channels straight away.

I'll have another look tomorrow.

Thanks,
Kevin

[diyelectromusic]

Oh hey - yes, that works! Sending noise to all channels really disambiguates what is going on - maybe I was just getting confused with which frequencies were ending up on which channels!? Oh well.

Yes if I send:
osc sine 110 1
osc sine 110 2
osc sine 220 3
osc sine 220 4
osc sine 440 5
osc sine 440 6
osc sine 880 7
osc sine 880 8

Then I can hear different octaves on each module.

That's good - sorry about that - it all works after all :)

Update: ok, so maybe part of the "problem" is that the PCM5102 seems to remember its last frequency after running a stop command, so when next running start sndi2s, I wasn't get a "clean start". Anyway, all ok now :)

Many thanks,
Kevin

[rsta2]

No problem. Good, that it works now! This test program is not perfect, I know, that's why it's in the test/ directory. ;)

There is another commit on the develop branch, which harmonizes the parameters of the constructor of the I2S driver class for all Raspberry Pi models.

You are welcome,
Rene

[rsta2]

Yes, only the selected channel is affected. I went fore and back now between channel 1/2 (GPIO21) and channel 3/4 (GPIO23).

[diyelectromusic]

I have a branch of MiniDexed that supports this now: https://github.com/diyelectromusic/MiniDexed/commits/QuadDAC8Chan/

@rsta2 I wondered if you'd take a look at the changes and see if you think they are correct.

One thing I wasn't sure about is the chunksize and number of queue frames. The one I wasn't sure about is https://github.com/diyelectromusic/MiniDexed/blob/main/src/minidexed.cpp#L254 which seems to equate chunk size with number of queue frames... I wondered if this should be GetChunkSize () / 2 here too, and should therefore be updated to be GetChunkSize () / 8 if supporting 8 channels rather than 2.

The default chunk size is 256 for RPi > 2, so I've upped that to 1024 for 8-channels.

Grateful for any thoughts or comments :)

Thanks again,
Kevin

[rsta2]

@diyelectromusic What I have seen quickly so far looks good. But the number of allocated frames for the sound queue should be: chunk_size * 2 / channels The reason is, that there are two cyclic DMA buffers of chunk size managed by the hardware sound drivers. When one buffer is filled by the sound rendering process, the other is sent out by the driver. So there must be twice the buffer space available in the sound queue, so that the hardware driver can copy half the queue size into the next DMA buffer in a row, when the previous one has been sent out and there is still room in the queue for the sound rendering process to be filled. The queue size is given in frames. One frame consist of 2 or 8 samples (== number of hardware channels). A default chunk size of 1024 for 8 channels should be OK. Rene

[diyelectromusic]

Ah I see - many thanks. I hadn't picked that up at all from the API descriptions! :)

I'll update that now.

Incidentally is that also why the following line uses QueueSizeFrames / 2? https://github.com/diyelectromusic/MiniDexed/blob/QuadDAC8Chan/src/minidexed.cpp#L1116

Thanks again.
Kevin

[rsta2]

This starts the sound rendering, when at least half the sound queue is empty. If I remember well, I did some tests at the time, when I wrote this, and this worked well. I cannot see a reason, why this should be changed for 8 channels.