I have a question beacause I got two contradictory information from two reputable sources.
A dac diyer my friend told me that the I2S standard is always at 32 bit and during the conversion in the dac, the last 8 bits or 16bits are just set to 0.
But I remember that @iancanada once told me that only the GPIO of a Rpi can output true 16 or 24 bit during audio reproduction.
Since the Rpi is I2S standard, is the output forced always to 32 bit? Or no?
A dac diyer my friend told me that the I2S standard is always at 32 bit and during the conversion in the dac, the last 8 bits or 16bits are just set to 0.
But I remember that @iancanada once told me that only the GPIO of a Rpi can output true 16 or 24 bit during audio reproduction.
Since the Rpi is I2S standard, is the output forced always to 32 bit? Or no?
Its very common for I2S from USB board to be 32-bits and zero padded as needed at the low order bits.
That said, its also possible for I2S to be 16 or 24 bits per channel. In that case BCLK frequency is reduced as needed so that no zero padding is required.
That said, its also possible for I2S to be 16 or 24 bits per channel. In that case BCLK frequency is reduced as needed so that no zero padding is required.
I'm not at RPi Linux audio driver programmer. I can just tell you its part of the I2S spec that 16,24, or 32bits per channel are permitted.
You might try asking over in the "PC Based" forum. That's where most of the linux guys seem to hang out.
You might try asking over in the "PC Based" forum. That's where most of the linux guys seem to hang out.
Different chips support different sets of I2S parameters, see datasheets for details. Normally the device providing the clocks determines which is used - so long as every chip on the bus supports the one used it should just work.
H
HAYK
In recent years, the Philips I2S formar rules are no more respected. The ck is always 64 x ws what ever is the bit number as if 32bit per channel is transmitted.
I2S bus specification does not dictate frame length so 32-bits or 16-bits are both "according to standard". Typically 32-bits is used for 24-bits as well. I'm not an expert on RPi but I assume RPi I2S uses GPIOs as well so it should be possible to output 16-bit I2S. However I'm not sure if the RPI I2S libraries or firmware support that directly.
There are several standard ways of transmitting data through I2S. The common ones are covered in the section of the DAC data sheet that talks about the I2S interface timing.
Tom
Tom
The I2S/PCM interface of RPi supports any channel length between 8 and 32 bits - see register TXC_A:CH1WID/CH2WID in https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf page 123.
The linux driver configures this register at every opening the device from the required hw_params https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L354 https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L429-L438 https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L519-L522 The format in HW params is constrained either by a specific DAC driver (e.g. https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/allo-boss2-dac.c#L942C39-L944) or in DTS file for DTS-configured cards, like https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master/blob/master/i2smaster.dts#L41
Of course for slave mode the incoming bclk must fit the requested sample width. For master mode RPi sets up its limpy bclk (https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/) to fit the requested sample length https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L413-L427
The linux driver configures this register at every opening the device from the required hw_params https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L354 https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L429-L438 https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L519-L522 The format in HW params is constrained either by a specific DAC driver (e.g. https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/allo-boss2-dac.c#L942C39-L944) or in DTS file for DTS-configured cards, like https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Master/blob/master/i2smaster.dts#L41
Of course for slave mode the incoming bclk must fit the requested sample width. For master mode RPi sets up its limpy bclk (https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/) to fit the requested sample length https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/bcm2835-i2s.c#L413-L427
That's not breaking the standard - you can transmit less bits than the available slots by padding the LSBs with zeroes, no requirement exists for using the minimum word size, and lots of sigma-delta's these days are 24+ bits resolution.
H
HAYK
The original rule gives the number of ck to be that of number of bits transfered. That is 2x16bit was 32ck, or 2x8bit, 16ck.
Now whatever is the word length, the ck is always 64.
Now whatever is the word length, the ck is always 64.
The BCLK multiple is anything configured on the I2S master. The actual multiple depends on the hardware capabilities and interface configuration. 64xFs is the most common in new designs, but not always. Often the default register values in ARM I2S interfaces configure 32xFs (i.e. 16bit slot) - RPi being the example.
The only hard and fast rule is a minimum of one bit clock cycle per data bit. BCLK can be as high as 128Fs with Fs still only 44k1.
Some Rockchip ARM's I2S can have TDM 16 slots of 32 bits (but only 8 slots written/read) -> BCLK 512Fs, maybe there are TDMs with 32 slots 🙂
RPi GPIO can output both true (physically) 16bit and true 32bit. However GPIO can not output true 24bit. And 24bit music will be in 32bit package with last 8bits fill 0.
Ian
Ian
I have used RPi4 I2S -> ES9038Q2M with slot width 24 bits, lrclk 768kHz (modified driver with the rate limit raised), bclk 48Fs = 36.8MHz, 24bit alsa format S24_3LE. Unfortunately ES9822Pro supports only 32bit slot, so I had to raise the bclk to 64xFs and use the 32bit format S32LE (or S24LE, also 32bit wide) for both chips to work together. It required inverting bclk in the corresponding RPi I2S register by the driver to account for signal delays at this samplerate.
Why should the 24bit slot not work?
Why should the 24bit slot not work?
Last edited:
24bit format needs bck clock times of 3 of the frequency of Fs, it will be very difficult for a digital system to process and to keep the low jitter performance. Normally, times of 2 only.
Ian
Ian
Clocking is a different issue, we were talking about capability of the I2S interface.
My design uses external clock Si5340D with PLL VCO running at around 13GHz, integer-dividing (Si5340D has no fractional divider) all the required frequencies incl. 128xFs MCLK for sync ESS DAC/ADC, 48/64xFs BCLK, Fs LRCLK, I2S slaved.
When using the internal RPi clocks (I2S master), the bcm2735_i2s driver will configure the I2S jittery MASH fractional divider to generate any BCLK = samplerate x channels (2) x sample width - I already linked the code doing that. And the BCLK->LRCLK divider inside the I2S interface will just integer-divide by 48 instead of by 64, no jitter involved. That's why it's easy for the interface to support any bit width with 1bit step (as specified in the datasheet and implemented in the driver). The jitter for fractionally-divided 48Fs BCLK will be just as horrible as for 64Fs BCLK due to low frequency of the PLLed clock and low bit resolution of the subsequent fractional divider - again hinting at my test https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/
Yes, using 64Fs with fixed-frequency crystal master clock is technically correct compared to 48Fs as there may be no crystals available for this frequency and the DAC master clock is not multiple of 48Fs, but that does not bother the RPi I2S interface 🙂
My design uses external clock Si5340D with PLL VCO running at around 13GHz, integer-dividing (Si5340D has no fractional divider) all the required frequencies incl. 128xFs MCLK for sync ESS DAC/ADC, 48/64xFs BCLK, Fs LRCLK, I2S slaved.
When using the internal RPi clocks (I2S master), the bcm2735_i2s driver will configure the I2S jittery MASH fractional divider to generate any BCLK = samplerate x channels (2) x sample width - I already linked the code doing that. And the BCLK->LRCLK divider inside the I2S interface will just integer-divide by 48 instead of by 64, no jitter involved. That's why it's easy for the interface to support any bit width with 1bit step (as specified in the datasheet and implemented in the driver). The jitter for fractionally-divided 48Fs BCLK will be just as horrible as for 64Fs BCLK due to low frequency of the PLLed clock and low bit resolution of the subsequent fractional divider - again hinting at my test https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/
Yes, using 64Fs with fixed-frequency crystal master clock is technically correct compared to 48Fs as there may be no crystals available for this frequency and the DAC master clock is not multiple of 48Fs, but that does not bother the RPi I2S interface 🙂
Last edited:
Not me, but engineers at SiliconLabs (before the clocking products line was sold to Skyworks) kindly did, at my request (actually great service and support, helping me with the clock configuration, no experience with Skyworks though).
For my purpose the clock performance is sufficient, while the flexibility to generate any suitable frequency for ADC/DAC is invaluable. No TI clock gen could go down to Fs https://e2e.ti.com/support/clock-ti...-options-for-generating-1mhz-clocks-i2s-lrclk
But again - that is not related to the I2S interface and its capabilities.
For my purpose the clock performance is sufficient, while the flexibility to generate any suitable frequency for ADC/DAC is invaluable. No TI clock gen could go down to Fs https://e2e.ti.com/support/clock-ti...-options-for-generating-1mhz-clocks-i2s-lrclk
But again - that is not related to the I2S interface and its capabilities.