Yes each sample is clocked syncronised. So the dalay of each samle is constant when the stream is not reset.
The trouble arises when two RPIs are used. Then we have 2 buffers and software that is not syncronised at all. If a all DSP is used, the latency difference between two DSPs are much smaller than two RPIs with linux and alsa
The proof is trying to have a to small byffer size. The buffer will overflow or underrun.
And we will never know how much the buffer is filled before alsa starts to read from the buffer.
So if ALSA starts forom the 36th sample in buffer on one RPI and from the 56 sample on the other there will be a constant 20 sample delay between the early reading RPI and the late reading RPI. And then you have clock drift on top of that during play
Last edited:
This is a good advice. Thanks for this. From this point of view the XMOS based multichannel USB variant looks better. I have to admit this.
May I ask what the case would be if I switch from Raspi Hardware to "normal" PC Hardware? As I understood CamillaDSP can be run under normal Linux as well. Taking a conventional PC mainboard and adding 4x soundcards each having a TOSLINK input and output would work (for example 4x Sound Blaster Z SE)? Working in the meaning of handling so many channels (I guess each is 7.1) and in relation to the timing when using the 4 individual TOSLINK outputs? Most likely PCIe should be better than having 4 USB devices in timing accuracy. Is this correct?
I think the input buffer size is the most important parameter, as long it is ARM or intel hardware. Eg. system with advanced operating system and not a real-time operating system (RTOS) or non operating system prosessing
But this is a very complex topic that i have not dug myself into.
So i don't know how to get a predictable latency from a none microcontroller/DSP system. But i do know that the microcontroller/DSP selling point are predictable latency https://www.analog.com/en/technical-articles/planning-for-success-in-real-time-audio-processing.html
But this is a very complex topic that i have not dug myself into.
So i don't know how to get a predictable latency from a none microcontroller/DSP system. But i do know that the microcontroller/DSP selling point are predictable latency https://www.analog.com/en/technical-articles/planning-for-success-in-real-time-audio-processing.html
Last edited:
Thanks. Yes, I fear this is the real point. Most likely a solution like miniDSP MCHStreamer is the best. I considered to implement a multichannel USB to I2S interface on a STM32. But this alone is a project with big effort...
IMO there is no serious reason to use Rpi + CDSP for multichannel DSP. There are other SBCs with up-to-date kernel support which support proper 8ch I2S. E.g Radxa has boards with 6.x kernels, running on Rockchip SoCs.
The Radxa CM5 compute module should have complete 8ch I2S in/out available, thanks to the clever use of three 100-pin headers, instead of just two on RPi CM4 (and on all other non-broadcom clones of the CM4). Of course it requires a special board designed, but that board can be combined with the I2S codecs. Radxa team says CM5 boards with integrated eMMC should become available within this month (for now only non-eMMC boards are available).
Their CM3 with the weaker RK3566 but all 8 channel I/O lines is readily available. Again an integration board is required.
Their CM3 with the weaker RK3566 but all 8 channel I/O lines is readily available. Again an integration board is required.
this is very interesting, thank you. Your idea was to implement a own software for doing the convolution or to use CamillaDSP? There are some STM32 H7 (?) which may be used for the purpose as well. But my hope was using CamillaDSP to have less trouble from the software side.
CDSP runs perfectly on other ARM64 SBCs, e.g. https://www.diyaudio.com/community/...io-gadget-rpi4-otg.342070/page-7#post-7297885 , it's not limited to RPi.
Just a variant.... I use an RME Digiface USB - the toslink version. This gives me 4 pcs of stereo Toslink out for 8 channels. If I could find an unit that did: 4 toslink ADAT in -> 8 toslink 24/44 out, I could feed 16 channels... This contraption should have one common sync source possible so any deviation would stem from DAC toslink sync handling. I think it could be OK...
//
//
can you say something about general Linux feasibility of this device? I was not sure about this because in the description special drivers were mentioned.
By the way another question: what is the recommended software for calculating FIR coefficients for very long linear phase filters for a 4 way system? I tested pyFDA what looks promising to me. But seems to have issues when using longer filter length (> 4096).
Initial measurements of the horns (when finished) can be done with a very simple 2.0 setup for each way individually. Hence I have some time left for introducing myself better to filter design ... Perhaps the initial measurements are so bad that I give up after the second smallest horn. I hope this is not the case. But the possibility exists. In comparison the companies like Avantgarde Acoustics I have nearly zero knowledge. But even in this state I do not understand all design decisions made by the experts.
As I recall it, no Linux support I'm afraid. But it was some time ago I checked - better search...
Useful tool for fir filter is rePhase. There is a thread on the forum...
//
Useful tool for fir filter is rePhase. There is a thread on the forum...
//
I found that Radxa Rock 5A has all 8 channels of i2s on the gpio header: https://wiki.radxa.com/Rock5/hardware/5a/gpio
Nice little board, but it seems pretty difficult to buy one :/
@HenrikEnquist : I got CM3 from AllNet.china and it went OK. They seem to carry 5A https://shop.allnetchina.cn/collections/rock5-model-a/products/rock5-model-a?variant=44289279394108
may be I can direct the discussion even in another direction. As Elon told me, an engineer should not be happy to solve a problem that shouldn't exist. Perhaps this is the case with multichannel I2S as well. I mean all the typical devices to be connected are DACs or fully digital amplifiers. Both normally have USB inputs. To use 4 USB devices on one device perhaps is not a good idea because of timing uncertainty (I'm not sure wether it can be guaranteed that all audio data is packed into one stream everytime). But as far as I know MACOS gives the possibility of sound device aggregation. This means that one of the devices is taken as clock master, the others are slaves. Perhaps this is why MACOS is used by many sound professionals. Hence using a MAC as platform for camillaDSP is perhaps the most versatile and elegant way? A TOSLINK input maybe can be added using USB or the MAC is the streaming device itself.
Someone here tried that, and the verdict was that the aggregate device doesn't sync the devices well enough to be useful for crossovers and such..
Ad Radxa 8ch boards:
Radxa RK3568 CM3 + CM3 IO - 8ch OUT + 8ch IN (I2S1).
I tested the combo this week, the I2S runs stable at 8ch up to 384kHz. 768kHz is above the board HW capabilities http://lists.infradead.org/pipermail/linux-rockchip/2023-September/040677.html due to only 32-locations I2S-DMA FIFOs (RPi4B has 64-locations FIFOs, allowing safe 768kHz)
The USB-gadget (DWC3) works (but I did no tests, only noticed the working RNDIS composite function by default configured by Radxa).
Radxa RK3588S Rock5A - 8ch out, 6 ch in (I2S1) - missing SDI2
Radxa RK3588S CM5 - 4ch OUT + 4ch IN + 4ch OUT/IN (shared pins in the SoC) (I2S0), 8ch OUT + 8ch IN (I2S1 - SDI3 and SDO0 have onboard 2k2 pullup resistors (designed for the shared I2C6) but hopefully that should not hurt). That means CM5 should be usable for synchronous 16ch OUT (assuming the alsa "multi" plugin manages to start the DMA stream on both interfaces within the same audio frame which is likely), master/slave mode including MCLK IN.
No pinout for CM5-IO board available yet.
Maximum samplerate remains to be tested (I do not have any RK3588 yet), I would assume at least 384kHz as the I2S + DMAC IP cores of RK3588 seem identical to RK3568, extra I2S pcms are specced at 768kHz + their DMA controller clocked by the same clock), and the manufacturing process is 8nm (vs. 22nm).
Radxa RK3568 CM3 + CM3 IO - 8ch OUT + 8ch IN (I2S1).
I tested the combo this week, the I2S runs stable at 8ch up to 384kHz. 768kHz is above the board HW capabilities http://lists.infradead.org/pipermail/linux-rockchip/2023-September/040677.html due to only 32-locations I2S-DMA FIFOs (RPi4B has 64-locations FIFOs, allowing safe 768kHz)
The USB-gadget (DWC3) works (but I did no tests, only noticed the working RNDIS composite function by default configured by Radxa).
Radxa RK3588S Rock5A - 8ch out, 6 ch in (I2S1) - missing SDI2
Radxa RK3588S CM5 - 4ch OUT + 4ch IN + 4ch OUT/IN (shared pins in the SoC) (I2S0), 8ch OUT + 8ch IN (I2S1 - SDI3 and SDO0 have onboard 2k2 pullup resistors (designed for the shared I2C6) but hopefully that should not hurt). That means CM5 should be usable for synchronous 16ch OUT (assuming the alsa "multi" plugin manages to start the DMA stream on both interfaces within the same audio frame which is likely), master/slave mode including MCLK IN.
No pinout for CM5-IO board available yet.
Maximum samplerate remains to be tested (I do not have any RK3588 yet), I would assume at least 384kHz as the I2S + DMAC IP cores of RK3588 seem identical to RK3568, extra I2S pcms are specced at 768kHz + their DMA controller clocked by the same clock), and the manufacturing process is 8nm (vs. 22nm).
| specced max kHz | on rk3588s | DMAC | OUT-CH | IN-CH | lrclk | mclk | sclk | sdi0 | sdi1 | sdi2 | sdi3 | sdo0 | sdo1 | sdo2 | sdo3 | ||
| i2s0 | 192 | x | 0 | 8 | 8 | m0 | GPIO1_C5_d | GPIO1_C2_d | GPIO1_C3_d | GPIO1_D4_d | GPIO1_D3_d - WIFI_PWR_EN | GPIO1_D2_d | GPIO1_D1_d | GPIO1_C7_d | GPIO1_D0_d | GPIO1_D1_d | GPIO1_D2_d |
| i2s1 | 192 | x | 0 | 8 | 8 | m0 | GPIO4_A2_d | GPIO4_A0_d | GPIO4_A1_d | GPIO4_A5_d | GPIO4_A6_d | GPIO4_A7_d | GPIO4_B0_d - 2k2 pullup | GPIO4_B1_u - 2k2 pullup | GPIO4_B2_u | GPIO4_B3_u | GPIO4_B4_u |
| m1 | GPIO0_B7_d - HDMI_TX0_SCL_M0 | GPIO0_B5_d | GPIO0_B6_d | GPIO0_C5_u | GPIO0_C6_u | GPIO0_C7_d | GPIO0_D0_d | GPIO0_D1_u - 2k2 pullup | GPIO0_D2_u - 2k2 pullup | GPIO0_D4_u | GPIO0_D5_u | ||||||
| ¨ | |||||||||||||||||
| i2s2 | 192 | x | 1 | 2 | 2 | m1 | GPIO3_B6_d - GMAC | GPIO3_B4_u | GPIO3_B5_u | GPIO3_B2_d | GPIO3_B3_u | ||||||
| i2s3 | 192 | x | 1 | 2 | 2 | m0 | GPIO3_A2_u - GMAC | GPIO3_A0_u | GPIO3_A1_u | GPIO3_A4_d | GPIO3_A3_u | ||||||
| i2s4 | 192 | x | 2 | 8 | 0 | DPTX0 | |||||||||||
| i2s5 | 768 | x | 2 | 8 | 0 | EDP0/HDMI0 | |||||||||||
| i2s6 | 768 | 2 | 8 | 0 | EDP1/HDMI1 | ||||||||||||
| i2s7 | 768 | 2 | 0 | 8 | HDMIRX | ||||||||||||
| i2s8 | 192 | 2 | 8 | 0 | DPTX1 | ||||||||||||
| i2s9 | 768 | x | 2 | 0 | 8 | HDMI TX0 | |||||||||||
| i2s10 | 768 | 2 | 0 | 8 | HDMI TX1 |
Last edited:
This is really great info @phofman ... I have just finished build a Pi4B+CamillaDSP-based 8-channel DSP platform using the X6000-7.1 HDMI audio extractor board discussed in this thread.. it is all housed in a Pesante 3U case along with SMPS and 8 channels of amplification using the TPA3116 boards recommended by FauxFrench.
To take audio in from my TV and other equipment, I also created a custom ADC hat for the Pi, based around the CS5341 chip, although its performance is not that great (I'm guessing it needs an isolator). But that's another topic.
I am using this to drive 3-way speakers (so 2 channels for woofers, 2 for mids, 2 for tweeters and 2 spare) and CamillaDSP is the active crossover.
Anyway, it is working quite well. But one big problem is channel ordering for the HDMI extractor card, which is quite random. The channels will often start up in the order 7/8/1/2/3/4/5/6 or 8/1/2/3/4/5/6/7. Eventually, after some time, it fixes itself (I don't know why - I suspect some kind of resynchronisation gets triggered). My current workaround is just to leave it running 🙂
What I'm wondering, is whether I should consider a Radxa board for running this, and perhaps design a multi-channel DAC hat for the Radxa. The form factor of the Rock4C+ is identical to the RPi 4B, meaning that the holes I cut in the back panel of my case for the Pi will fit perfectly. Would you think the RK3399 chip is capable?
BTW, I know that multi-channel USB soundcards would work, and I have one, but the Pi's USB port faces externally so the soundcard would be outside, and I couldn't connect its outputs to the amplifiers which are inside the box. So this doesn't help me unfortunately.
(Incidentally I think the CM3 uses RK3566... RK3568 was in the Rock3A.. it's easy to type the chip number wrong!)
To take audio in from my TV and other equipment, I also created a custom ADC hat for the Pi, based around the CS5341 chip, although its performance is not that great (I'm guessing it needs an isolator). But that's another topic.
I am using this to drive 3-way speakers (so 2 channels for woofers, 2 for mids, 2 for tweeters and 2 spare) and CamillaDSP is the active crossover.
Anyway, it is working quite well. But one big problem is channel ordering for the HDMI extractor card, which is quite random. The channels will often start up in the order 7/8/1/2/3/4/5/6 or 8/1/2/3/4/5/6/7. Eventually, after some time, it fixes itself (I don't know why - I suspect some kind of resynchronisation gets triggered). My current workaround is just to leave it running 🙂
What I'm wondering, is whether I should consider a Radxa board for running this, and perhaps design a multi-channel DAC hat for the Radxa. The form factor of the Rock4C+ is identical to the RPi 4B, meaning that the holes I cut in the back panel of my case for the Pi will fit perfectly. Would you think the RK3399 chip is capable?
BTW, I know that multi-channel USB soundcards would work, and I have one, but the Pi's USB port faces externally so the soundcard would be outside, and I couldn't connect its outputs to the amplifiers which are inside the box. So this doesn't help me unfortunately.
(Incidentally I think the CM3 uses RK3566... RK3568 was in the Rock3A.. it's easy to type the chip number wrong!)
Just looking further, the Rock4C+ doesn't break out the I2S pins fully, so it's not feasible for more than 2 channels. I think my best option will be the Rock 5A. I2S0 is connected to an onboard codec, and I2S1_M1 pins are used for various other things. So the only real option is I2S1_M0.
As far as I can see, all pins are available on the 40p header except SDI1 and SDI2. Here is a table with the labels used in the Rock5A schematic
As far as I can see, all pins are available on the 40p header except SDI1 and SDI2. Here is a table with the labels used in the Rock5A schematic
| mclk | lrck | sclk | sdo0 | sdo1 | sdo2 | sdo3 | sdi0 | sdi1 | sdi2 | sdi3 | |||||||||||
| label | I2S1_MCLK_M0 |
|
|
|
|
|
|
|
|
|
| ||||||||||
| pin on 40p header | 35 | 36 | 12 | 40 | 13 | 11 | 15 | 38 | none | none | 32 |