Unfortunately I can't figure out how we can see the register map for the I2S peripheral. It seems to be under NDA and only accessible by Synopsys customers. The linux dwc-i2s driver has a comment in the interrupt handler about only handling two channels, but as far as I can see that's only relevant if using PIO to transfer data (not DMA). So perhaps 8 channels will work out of the box?
There have been a few commits recently on the driver:
https://github.com/raspberrypi/linux/commits/rpi-6.1.y/sound/soc/dwc/dwc-i2s.c
There have been a few commits recently on the driver:
https://github.com/raspberrypi/linux/commits/rpi-6.1.y/sound/soc/dwc/dwc-i2s.c
Every chinese SoC has register docs, while what has been released for RP1 is more like a product sales sheet. IMO only RPi-originated parts are detailed, the Synopsys IPs are lacking. Synopsys DWC2 docs were re-fromatted to RPi docs design in their previous https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf . Though it was very incomplete too, I had to talk to Synopsys engineer to fix stuff there https://lore.kernel.org/linux-usb/60def6a9-89f3-d7b9-4bc1-2f1a7a5ce769@synopsys.com/ -> https://github.com/raspberrypi/linux/issues/3447 .
I do hope RPi will release the info, or people will leak the Synopsys docs eventually (but every IP implementation is customized, Minas from Synopsys had to reach for documentation specifically for BCM2711 which differs in some registers from some Intel implementations available online). Sad for a company/foundation which prides itself with open and transparent approach while RPi chips are much more secretive than standard ARM SoCs from China.
This is what I was able to find so far. DWC I2S docs are spread through some custom-application datasheets. This http://www.pianyifa.cn/images/chips/datasheet/HS6621Cx_Datasheet_V1.5.pdf starting page 87 is quite detailed (why did RPi not release the same details?) . But it hides meaning of registers I2S_COMP_PARAM_1/2 which define instantiated number of channels. It only reads "Component Parameter 2 Register, Reset Value: Reset value depends on user configuration. For more information, refer to" and nothing more...
This datasheet is very sparse but details the I2S_COMP_PARAM_1 at page18/19 https://www.ampedrftech.com/datasheets/ACH1190_Datasheet.pdf .
Nevertheless, this register is never written in linux kernel, only read, initially configuring hw_params max channels (used by alsa to limit channels requests). All datasheets talk about "instantiation of the block" based on these params. IMO these are instantiated at RPi boot, before kernel takes over. IF RPi people configured only 2 channels to be instantiated, I do not know if there is a way to change that from the kernel. Maybe it's 8ch (4 I2S channels in that register) and all is OK, hw_params will allow up to 8 channels, only the appropreate GPIO pins will have to be switched to the corresponding I2S mux.
The RPi docs and information are sadly poor, feels like windows.
I do hope RPi will release the info, or people will leak the Synopsys docs eventually (but every IP implementation is customized, Minas from Synopsys had to reach for documentation specifically for BCM2711 which differs in some registers from some Intel implementations available online). Sad for a company/foundation which prides itself with open and transparent approach while RPi chips are much more secretive than standard ARM SoCs from China.
This is what I was able to find so far. DWC I2S docs are spread through some custom-application datasheets. This http://www.pianyifa.cn/images/chips/datasheet/HS6621Cx_Datasheet_V1.5.pdf starting page 87 is quite detailed (why did RPi not release the same details?) . But it hides meaning of registers I2S_COMP_PARAM_1/2 which define instantiated number of channels. It only reads "Component Parameter 2 Register, Reset Value: Reset value depends on user configuration. For more information, refer to" and nothing more...
This datasheet is very sparse but details the I2S_COMP_PARAM_1 at page18/19 https://www.ampedrftech.com/datasheets/ACH1190_Datasheet.pdf .
Nevertheless, this register is never written in linux kernel, only read, initially configuring hw_params max channels (used by alsa to limit channels requests). All datasheets talk about "instantiation of the block" based on these params. IMO these are instantiated at RPi boot, before kernel takes over. IF RPi people configured only 2 channels to be instantiated, I do not know if there is a way to change that from the kernel. Maybe it's 8ch (4 I2S channels in that register) and all is OK, hw_params will allow up to 8 channels, only the appropreate GPIO pins will have to be switched to the corresponding I2S mux.
The RPi docs and information are sadly poor, feels like windows.
hey interesting thread,.
i would ne glad to know If a multi dac solution could also bei done with Ian Canada Boards Like this
i would ne glad to know If a multi dac solution could also bei done with Ian Canada Boards Like this
IAN CANADA MCFIFO Multi-Channel I2S/DSD FIFO Buffer
IAN CANADA MCDUALXO Multi-Channel Clock Board
https://www.audiophonics.fr/en/diy-...multi-channel-i2sdsd-fifo-buffer-p-17125.htmlThat is what I am planning. I have 4 stereo AK4493 DAC boards. Using a miniDSP MCH steamer to go USB to multichannel I2S from a Mac mini. Still need to test it out properly.
Just to throw another idea for a 8 channel interface in there, there is also the ESI Gigaport eX
Yes. But it looked like he tried to do a noise measurement and got what looks like a distortion FFT...
Do you think that device is OK - I need 8 ch for some experiments where the experiment and evaluation should not be failing due to a too poor DAC...
//
Do you think that device is OK - I need 8 ch for some experiments where the experiment and evaluation should not be failing due to a too poor DAC...
//
IIUC those charts were just noise floor, no digital signal being fed to the gigaport. The measured peaks were almost certainly USB-processing artefacts.
@TNT
In the RMAA measurements the SNR is around 109dB.
https://prosound.ixbt.com/interfaces/esi-gigaport-ex.shtml
Although SNR is always tricky and very depending on averages.
It's a bit strange, because the AK4358 datasheet clearly says 112dB, not 114dB.
On IXBT they claim that the input was being done with a Lisk Audio MOD3, with a SNR of 122dB.
So with a loopback measurement, that would give about 111dB best case scenario.
Loosing another 2dB within the entire path, is not that crazy.
The JRC4580 are not the best opamps in the world, we also don't know what caps they are using (often X7R or even X5R, yikes).
So maybe they could add a bit of noise.
In the RMAA measurements the SNR is around 109dB.
https://prosound.ixbt.com/interfaces/esi-gigaport-ex.shtml
Although SNR is always tricky and very depending on averages.
It's a bit strange, because the AK4358 datasheet clearly says 112dB, not 114dB.
On IXBT they claim that the input was being done with a Lisk Audio MOD3, with a SNR of 122dB.
So with a loopback measurement, that would give about 111dB best case scenario.
Loosing another 2dB within the entire path, is not that crazy.
The JRC4580 are not the best opamps in the world, we also don't know what caps they are using (often X7R or even X5R, yikes).
So maybe they could add a bit of noise.
OK - thanks! I might actually take a chance with this one. I aim to do time shading for a 7 segment bending wave line source as an "experiment" - this should fit the bill... ch: 4-3-2-1-2-3-4 / L+R...
//
//
This is definitely a feasible approach, but a SBC with an 8-channel DAC attached seems nicer to me (not to mention more compact and most likely cheaper). I guess I need to wait and see if RPi 5 has 8 usable channels (but it would be very weird to define 8 I2S pins if they can't be used).