Raspberry Pi B+ Digital Audio

I2S AUDIO

Although the Raspberry Pi has built-in analog audio output, the interest here is in digital audio output in particular I2S output signals for direct connection to digital to analog converters. I explored a bit the digital audio capabilities of the Raspberry Pi a while ago [link]. Here is an update with more accurate information.

The digital audio capabilities of the Raspberry Pi B+ have not changed from previous versions. The I2S audio is supported by the Broadcom BCM2835 [link]  peripheral SoC chip. The datasheet shows that the PCM audio interface consist of 4 signals, notice that there is no Master Clock signal:

• PCM_CLK – bit clock.
• PCM_FS – frame sync signal. Frames can be up to 32 bit wide
• PCM_DIN  – serial data input.
• PCM_DOUT – serial data output.

In addition, for more advanced configurations, the device can be configured as master or slave: “the direction of the PCM_CLK and PCM_FS signals can be individually selected, allowing the interface to act as a master or slave device”. In normal operation, it is configured as a master device.

In the Raspberry Pi B+, The I2S output are assigned to the following pins:

EXTERNAL CLOCK

The audio frequencies (the PCM _MCLK) are supposedly generated by the use of a discrete 0n-board 19.2 MHz crystal. Unlike the BeagleBone Black, where there are facilities (pins) to feed an external master clock.

The frequency that is generated at any of the I/O pins, say the bit clock, is obtained by dividing the source clock (19.2 MHz oscillator) by configuring a clock division register with an integer part and a fractional part as indicated by the datasheet excerpt shown below:

The Datasheet indicates that the clocks are generated by “noise-shaping MASH dividers” which are fractional dividers. It also says that “The fractional dividers operates by periodically dropping source clock pulses”. I believe this post has an example on how this is actually implemented [link].

The way that a 3.25x clock divider is implemented is by dividing by 3x for some periods and 4x for other periods, with the average being 3.25x. In this case the repeating pattern will be (3, 3, 3, 4). That is shown in the following scope capture. Note that the first three periods are divided by 3 and then the next is divided by 4.

The way this is implemented in the device is to divide by the smaller divider and then extend the high pulse width by one clock cycle periodically.

We can find the integer divider and fractional divider based on MASH 1 (see above) and determine what is the maximum and minimum output frequency:

• Source clock: 19,200,000 Hz
• Sample rate: 44,100 Hz; bit clock (64fs)=2,822,400 Hz
• Actual divisor: 6.8027. Integer part=6
• Fractional divisor: =0.8027×1024=822 (round off)
• Maximum frequency: 19,200,000/6=3,200,000 Hz (50 KHz sample rate)
• Minimum frequency: 19,200,000/7=2,742,857 Hz (42.9 KHz sample rate)
• Average frequency: 19,200,000/(6+(822/1024))=2,822,394 Hz (44.1 KHz sample rate)

Well, aiming at 44.1KHz sample rate frequency and getting a frequency variation from 42.9 KHz to 50KHz, this can’t really work for digital audio. Clearly there has to be a better way to generate these clock frequencies.

GENERATION OF DIGITAL AUDIO FREQUENCY CLOCKS

Much of the credit for enabling I2S output in the RPi (and the proper generation of clock frequencies) is due to the discussion in the Raspberry Pi forums [link] and work of Florian Meier in his master thesis “Low-Latency Audio over IP on Embedded Systems” [link] who subsequently developed the basic “ALSA SoC I2S Audio Layer for Broadcom BCM2708 SoC” audio kernel driver [link]

There it is explained that in order to get good clocks, one has to use integer division but with a 19.2 MHz clock, it is impossible to arrive at 32fs or 64fs bitclocks (e.g. 64x48KHz=3.072 MHz). Therefore other internal clocks must be used.

According to this post [link] the clocks sources are:

0     0 Hz     Ground
1     19.2 MHz oscillator
2     0 Hz     testdebug0
3     0 Hz     testdebug1
4     0 Hz     PLLA
5     1000 MHz PLLC (changes with overclock settings)
6     500 MHz  PLLD
7     216 MHz  HDMI auxiliary
8-15  0 Hz     Ground

The logical choices are the external 19.2MHz and the highest stable frequency clock which is the 500 MHz clock (highest frequency generates a more accurate clock after fractional clock division)

The author presents two solutions:

• Use the 19.2 MHz oscillator with integer division for DACs that do not require a specific ratio of bit clock to frame sync (e.g. 32fs for 16 bit data) as long as there are at most enough bit clock cycles within a frame sync cycle to contain the desired word length
• Use the 500 MHz internal PLL with fractional division for DACs that do require a specific ratio of bit clock to frame synch (e.g 32fs or 64fs)

The first solution says that it is possible to use, say 40fs, to sent 16 bit samples (16bitx2=32bit per frame) because you can transfer all 32 bits in a 40 bit frame. If you can use 40fs for the bitclock, then 40x48KHz= 1.920 MHz which is 19.2 MHz/10. The following excerpt from the thesis explains these two approaches:

We notice that integer division of the external 19.2 MHz clock only works for 48KHz and 96 KHz and for DACs that can operate at 40fs (80fs if we want to pass 32×2 bits per frame). The current version of the code is using 50fs and 100fs which also works.

For the 44.1KHz sample rate or for bitclock requiring 32fs or 64fs, then the first solution with fractional division is used on the 500 MHz PLLD clock

WHY 19.2 MHz CLOCK?

The fact that no clean clocks can be generated in the digital audio frequency range, tells us that this oscillator was not really meant to be used for digital audio. Now why did the designers of RPi use a 19.2 MHz clock?

I have searched extensively and cannot find a “reason” for the 19.2 MHz frequency. If it were digital audio, a more logical selection would have been 24.576 MHz in order to cleanly support 64fs 48KHz sample rate (like the BeagleBone Black).

A better reason is to use this clock for the on-board PWM audio. One can easily generate a 48KHz carrier frequency (19.2MHz/40) and a resolution of 16 bit would require a frequency of approx 64 KHz (19.2MHz/30). In actually, it has been reported that the resolution is in the neighborhood of 11 bit or 2048 levels which can be obtained by dividing 19.2MHz by a factor of 9375.

SLAVING THE RPi

A better solution is to configure RPi as a slave device and the DAC as a master device.

The DAC can provides a much more accurate clock to the RPi by feeding the Bitclock. I don’t think is being done by the current crop of DACs (the ones based on the PCM5122)  but the capability is there for both in the RPi (“clock slave mode” and “frame synch slave mode”) and the PCM5122 as shown in the following excerpt from the datasheet:

Here is what is required to set the DAC in Master Mode, say for example the PCM5122.

1. RPi detects the sample rate of the clicked-to-play track.
2. RPi has a way to indicate the sample rate (for example using GPIO pins).
3. Microcontroller reads sample rate.
4. Microcontroller programs the appropriate frequency by generating an appropriate master frequency from the PLL and setting the appropriate divider to generate the bitclock.

Other considerations:

• Timing of the different events. For example, wait until the microcontroller programs the DAC to the appropriate clock frequency before staring the data stream (DMA) in the RPi.
• Selection of external clock. For example use a single frequency clock, say a multiple of 44.1KHz in order to take advantage of integer divider only when dealing with frequencies multiple fo 44.1KHz.

COMPARISON WITH OTHER DEVICES

Here is the previous comparison table with some updated observations (italics)

Parameter	Rasberry Pi	BeagleBone Black	Comments
Native I2S support	Yes	Yes	Both platforms can support I2S output, Custom drivers have been developed by the audio community
I2S Sample Rate limitation	Up to 192KHz (because the on-board clock is 19.2MHz)	Only 48KHz family (because the on-board clock is 24.576MHz and integer clock dividers)	BBB supports 48KHz, 96KHz, 192KHz and 384KHz. RPi supports 44.1KHz, 48KHz, 88.2KHz, 96KHz, 176.4KHz and 192KHz (in theory). RPi uses “fractional clock dividers” to generate the 44.1KHz sample rate family as explained above
Support for USB DAC	Yes (LAN9512 chip [link])	Yes (Built-in in the main processor)	USB in the RPi goes through a built-in HUB and it is shared with the LAN controller within the USB/LAN chip. USB in the BBB is natively supported by the main processor; LAN has a separate chip
Support for external, low jitter clocks	Not possible unless you replace the on board oscillator and modify the driver	Yes with custom boards and custom s/w: [link]	The master clock in BBB may be provided externally by disabling the on-board audio-freq clock.The Master clock in the RPi seems internally generated and there is no I/O pin to feed an external master clock
Master clock output	No	Yes (from on-board clock)	The Master clock in BBB is provided by the on-board 24.576MHz and fixed at this frequency and can be directly accessed from the outside. The Master clock of RPi seems internally generated but un-accessible from the outside. Without Master Clock, you can only use DACs that can operate asynchronously without a Master Clock input such as the ESS DACs or DACs that can operate with the master clock = bit clock
Built-in rechargeable battery operation	No	Yes [link]. Maybe	Rechargeable Battery operation in BBB would disable the 5V supply to the USB. Thus for USB operation, where the USB adapter takes the power from USB, BBB must be powered with 5V DC
Built-in Storage	No.  But the new model has plenty of USB ports for USB memory sticks	2 GB eMMC Flash	BBB can boot from the internal storage freeing the SD card for music storage. RPi requires that the OS be stored in the SD card (although it may be possible to also store music in the SD card)
Looks	The latest model looks Good	Good	🙂
Audio H/W and S/W community support	Large	Small
Price	$35	$55

Here is a summary of the phase noise measurements from this post [link]:

Observations

• The ESS9023 implements a “jitter eliminator” (asynchronous sample rate converter) but cannot eliminate all the jitter
• The clocks on the embedded boards have a lot of jitter. It also makes sense that the BBB has better measurement than the RPi. In the BBB, the 48KHz sample rate frequency is derived by integer division of the external clock. In the RPi, the 44.1KHz sample rate frequency is derived from the 500MHz clock which is derived from the external clock as explained above
• The “lowly” CD player is still a pretty good playback device in terms of jitter
• I would guess (and only a guess since the author does not identify these interfaces) USB-I2S-2 is an XMOS-based device based on how the clocks are generated and that USB-I2S-1 is a device based on an FPGA or CPLD using two external audio frequency clocks (where straight integer division is used)

SUMMARY

The current method of generating the clocks for digital audio in the RPi are far from perfect. The best clocks are obtained by integer division of the external clock and works for 48K and 96K sample rates and only if the DAC can accept 40fs or 80fs. For anything else, the clocks are derived from the 500MHz PLL through fractional division as explained above. It has been reported that the 500MHz clock itself is derived from the 19.2MHz external clock through a clock multiplier.

However imperfect as these clocks might be, there are a good number of DAC boards that have been developed and reported to work well with the RP1. As these products are being developed by audio fanatics, we can expect continuous improvements and enhanced approaches to better clock generation such as external reclocking and slave configurations.

For additional info, you can check the Raspberry Pi I2S discussion thread here: [link]

Advertisement