Search Results
AKM Verita 4490EQ DAC
(12/22/14- Updated with information from AKM support engineers -see register section)
It has been a long time semiconductor houses invested in a flagship product. Wolfson announced the WM8471 in 2007 and ESS announced the Sabre DAC in 2008. Recent investment has been concentrated in DACs for the broad consumer industry especially for the mobile segment. It is good to see a company still interested in investing resources for the “audiophile” segment.
AMK introduced the AK4490 this year and has recently made it available in production quantities. It differs upon the AK 4399 DAC in the following areas (yes, the spec for Dynamic Range is lower in the new chip):
| Parameter | AK4490 |
AK4399 |
| THD | -112 dB | -105 dB |
| S/N (Mono) | 123 dB | 126 dB |
| Max Sample Rate | 768KHz | 216 KHz |
| Built-in Digital Filters | 5 | 2 |
| Direct DSD (No conversion to PCM) | Yes | No |
| AVDD Max operating voltage | 7.2V | 5.25V |
Here is an overlay of the FTT measurement between the AK4490 and AK4399 (graph slightly shifted to the right to show the comparison) from the evaluation board data sheets. As seen, the AK4490 has a slight edge over the AK4399:
Increasing S/N by 3 dB
In order to “recover” the lost S/N in the new device as compared with the old device, The AK4490 can be operated with an analog supply of up to 7.2V. At 7V we gain 3dB S/N resulting in 126 dB for mono operation and therefore meeting the best specification of the old A4399 part.
Even though this is not documented in the current version of the AK4490 data sheet, it is documented in the AK4495 data sheet:
Thus one of the “mods” that can be made in this DAC is to run the DAC at the higher-end of the analog voltage operating spectrum.
KEY FEATURES
Built-in Digital Filters
(images taken from Ayre’s paper [link]):
The built-in digital filters consist of 5 selectable filters. They include all the “popular” filters developed so far by different vendors plus one additional filter with undisclosed response (super slow roll-off). The filters are described as follows:
Linear phase Sharp Roll-off (AKM notation: “no delay”): this is the “standard” sharp roll-off filter found is all DACs. It is also known as the “brickwall” filter. It is said that pre-ringing sounds unnatural.
Linear phase Slow Roll-off (AKM notation: “no delay”): this is also a “standard” filter found in all DACs. As in the linear phase sharp roll-off filter, it also generates pre-ringing, but trading lower amounts of pre-ringing with letting more aliased image through (theoretically increasing harmonic distortion).
Minimum delay Sharp Roll-off (AKM notation: “short delay”): this is also called the “minimum phase” or “apodizing” filter that was the rage a few years back. Whereas in the past audio engineers have insisted in phase linearity (meaning all frequencies have equal phase or delay), More recent research have shown that a “minimum phase” filter sacrifices some of the phase linearity (adds some phase distortion) for better time response. This filter removes all the “unnatural” pre-ringing but “dumps” all that energy to post-ringing. Implementation of this filter is also found in the Wolfson WM8741/8742 DACs
Minimum delay Slow Roll-off (AKM notation: “short delay”): this is a “more modern” type of filter also found in the Wolfson WM8741/8742 DACs. In addition to eliminating pre-ringing, this filter also incorporates slow roll-off and this reduces post ringing as well.
The properties of this filter are similar to the “MP filter” found in Ayres latest CD player.
Super Slow Roll-off: this filter is the differentiating feature (in terms of built-in filters) that this DAC provides. The AKM literature says “super slow roll-off filter with emphasized characteristics” (which really means nothing). There is some information in the marketing page as shown below.
The marketing information says the following [link]
Native DSD Support
Supports 2.8MHz (64fs), 5.6MHz (126fs) and 11.2MHz (256fs) DSD
According to AKM, the volume control module and the delta-sigma modulator can be bypassed for DSD resulting in “direct” DSD rendering. The AK4490 contains an integrated low-pass filter specifically for DSD data. The ultimate specified performance for SACD (as described in the Scarlet Book) can be easily realized with a simple external analog filter.
Notice the bypass path for DSD Data. The DSD data is received by the DSD interface and sent directly to the “SCF” (Switched Capacitor Filter) block. DSD filter can be selected at 50KHz, 100KHz or 150KHz cut-off.
Other Comparative Features
Resolution32 bit32 bit32 bit24 bit24 bit
| Parameter | AK4490EQ | ES9018 | ES9018K2M | WM8741 | PCM1794 |
| DR (Mono) | 123 dB | 135 dB | 127 dB | 128 dB | 132 dB |
| THD | -112 dB | -120 dB | -120 dB | -100 dB | -108 dB |
| Max SR | 768KHz | 384KHz | 384KHz | 192KHz | 192KHz |
| Output Mode | Voltage | V or I (best) | V or I (best) | Voltage | Current |
| Resolution | 32 bit | 32 bit | 32 bit | 24 bit | 24 bit |
| DSD Mode | DSD Direct and DSD to PCM | DSD to PCM | DSD to PCM | DSD Direct and DSD to PCM |
Just like the WM8741, the AK4490 supports “direct DSD” processing bypassing the volume control and delta-sigma modulator. And like the WM8741, there is no automatic switching between PCM and DSD.
I2S and DSD shared lines
In order to facilitate the playing of both PCM and DSD content, it is desirable to have the same lines transmit PCM and DSD data. We find that in the AK4490, the I2S and DSD signals are shared. Here is a post I write earlier concerning shared I2S/DSD signal lines: [link]
The table below shows compatible DACs (DACs that share that use the same lines for DSD and PCM) and interfaces showing how the DSD pins are mapped to the PCM/I2S pins:
| I2S Pins |
ESS9018 [link] |
PCM1795 [link] |
AK4399 [link] |
Amanero [link] |
SDTrans [link] |
XMOS Ref [link] |
| BCLK | DSD Clock | DSD Clock | DSD Clock | DSD Clock | DSD Clock | DSD Clock |
| LRCLK | DATA Left | DATA Right | DATA Right | DATA Left | DATA Left | DATA Left |
| DATA | DATA Right | Data Left | Data Left | Data Right | DATA Right | DATA Right |
The AK4490 DAC follows the mapping of the AK4399 which switches channels with the “conventional” channel mapping of USB interfaces. Likely it was the USB interface designers that took notice of the ESS9018 DAC and conformed the channel mapping to that chip.
Fortunately, there is channel remapping in at least the Amanero interface and there is channel remapping in the DAC itself as specified in the following table of the data sheet:
MONO=0, SELLR=1 says:
- Right channel input is mapped to Left channel output
- Left channel input is mapped to Right channel output
DIYINHK IMPLEMENTATION
I Just received diyinhk’s implementation of AKM’s new flagship DAC, the AKM AK4490EQ [link]. This is the first available diy board in the market (that I know of):
POWER SUPPLY LINES
The Diyinhk implementation follows (mostly) the AKM evaluation board and data sheet [link] but maximizes performance whenever possible (like in the selection of capacitor type and value). The board is powered by: 5V line, 3.3V line and +/- 12V line (for the output opamp).
The general layout of the power traces, decoupling capacitors and ground planes also follows the data sheet:
Grounding and Power Supply Decoupling:
To minimize coupling by digital noise, decoupling capacitors should be connected to AVDD and DVDD respectively. VREFHL/R and VDDL/R are supplied from analog supply in system, and AVDD and DVDD are supplied from digital supply in system. Power lines of VREFHL/R and VDDL/R should be distributed separately from the point with low impedance of regulator etc. AVSS, DVSS, VSSL and VSSR must be connected to the same analog ground plane. Decoupling capacitors for high frequency should be placed as near as possible to the supply pin.
Analog 5V supply lines (can operate up to 7.2V according to spec)
The 5V supply connects to VDD (5V Analog supply input) and Reference Voltage High (VREFH) -as recommended in the data sheet.
The differential voltage between VREFH-L/R and VREFL-L/R sets the analog output range. The VREFH-L/R pin is normally connected to VDD (analog 5V supply), and the VREFL-L/R pin is normally connected to VSS1/2/3 (analog ground). VREFH-L/R and VREFL-L/R should be connected with a 0.1µF ceramic capacitor as near as possible to the pin to eliminate the effects of high frequency noise…All signals, especially clocks, should be kept away from the VREFH-L/R and VREFL-L/R pins in order to avoid unwanted noise coupling into the AK4490.
In addition, according to the eval board manual, a large value capacitor between VREFH-L/R (Analog 5v) and VREFL-L/R (GND) improves the THD performance in accordance to the following graph:
The Diyinhk board is implemented with 2200 uF capacitors, achieving the best THD numbers. (The larger capacitor holds the reverence voltage stable -perhaps an even larger capacitor would further improve the low frequency THD numbers).
There is an option to use separate supplies for right and left VREF and VDD. This also follows the scheme implemented in the official evaluation board where the left VREF is separately powered from the right VREF.
Further, the AKM literature states:
Special designs techniques for sound quality are applied to each blocks for achieving balanced, smooth and powerful signal flow. In addition to L/R perfectly symmetrical layout, more than 5x trace width is used for signal line compared existing products, supplying rich current to analog signal output blocks. To achieve low impedance, two analog power supply pins and two signal reference pins are assigned for each channel, allowing the system to utilize thick PCB trace pattern giving low impedance sources.
The board takes advantage of this feature to use thicker lines for VREF and VDD
All 0.1 uF decoupling ceramic capacitors are C0G
The official evaluation board has a provision to separate the VREF from the Analog 5V VDD which is not implemented in this board. However, it is easy to mod and use separate supplies for VREF and Analog 5V VDD.
The evaluation board implements VREF with the following circuit:
3.3 V Supply Line (Analog 3.3V and Digital 3.3V)
There is a 3.3V analog supply pin and a 3.3V digital supply pin in the chip. The default implementation of the diyinhk board uses the same supply line but filters them with a ferrite bead. By removing the ferrite bead, the user can use separate supplies for the analog and digital 3.3V.
In the evaluation board, AVDD and DVDD are powered by separate regulators:
GROUND PLANE
The ground planes follows the recommended separation between analog and digital sides (along pins 17-18 and 45-46)
SOFTWARE INTERFACE
The older device, the AK4399 supported a 3-wire serial interface. This seemed a not too widely supported protocol (it was not SPI and could not find a similar protocol in Arduino libraries , but one could code the protocol “by hand” as it was just a serial protocol -never tried it though)
Fortunately the new DAC supports I2C protocol (and maintains support for the original 3-wire serial interface found in older DACs). This greatly facilitating the interface to a microcontroller such as Arduino because of their built-in support for more standard protocols such as I2C and SPI.
The advantage of using the S/W interface is that it supports features such as volume control and DSD which are not available through the H/W interface.
The following table summarizes these features that are available in H/W interface (parallel interface -by pulling hardware pins up or down) and S/W interface (serial interface -microcontroller control).
Not indicated in the table is the “super slow roll-off” filter which is enabled by a register setting in s/w mode.
REGISTER DEFINITION SUMMARY
(Updated with information from AKM support engineer)
Here I summarize the register settings and the different functions that can be programmed. I also attempt to do some “translating” of AKM’s vocabulary to more “traditional” vocabulary.
I was able to communicate with AKM to clarify the functionality of certain sections.
Register address: 00 (Control 1) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| Reset chip without initializing registers |_|_|_|_|x|x|x|_| Interface mode: 16bit, 24bit, 32bit, I2S, LJ... (1) |_|_|x|_|_|_|_|_| External digital filter clock: 768KHz/384KHz |_|x|_|_|_|_|_|_| Enable/disable external digital filter mode |x|_|_|_|_|_|_|_| Master Clock frequency Setting: auto/manual (2)(3) NOTES: (1)- The only requirement for bitclock is >= 2x bit depth. Bitclock could be 32fs, 48fs or 64fs. Not limited to always be 64fs as in ESS DACs (2)- Auto: detects master clock frequency and sampling frequency (44.1KHz, 96KHz, ...) automatically; sets oversampling rate (1x, 2x, 4x...) according to input MCKL (this is kind of obvious). Note: AKM calls sample rate "sampling speed" and assigns names to typical sample rates: 44-48KHz="normal", 88-96KHz="double", 175-192KHz="quad"... (3)- Manual: manually set the sampling rate (44.1KHz, 96KHz...) Use reg 01 and reg 05 for sampling rate setting. This means, in its simplest form, manually matching the sampling rate to the incoming data sample rate to use the highest oversampling rate allowed by the system and thus obtain best noise performance. This feature can also be used to select a different sampling rate (typically a lower oversampling rate); for example, if selecting "normal" for 44.1KHz allows 8x oversampling (512fs), selecting "double" results in 4x oversampling (256fs). This allows for experimentation with different oversampling rates and can be used to tailor the sound for those inclined to lower oversampling or even no oversampling. The use of lower oversampling results in higher noise for these kind of DACs. AKM indicates in the datasheet that using a lower oversampling rate (512fs to 256fs) results in a decrease of S/N of 3dB. Register address: 01 (Control 2) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| Mute/unmute |_|_|_|_|_|x|x|_| De-emphasis: Off, 32KHz, 44.1KHz, 48KHz |_|_|_|x|x|_|_|_| Manual setting of sampling speed: "normal", "double"... (1) |_|_|x|_|_|_|_|_| Short Delay/Traditional filter (Minimum/Linear phase) |_|x|_|_|_|_|_|_| Zero data detect mode: Separate channels or ANDed channels |x|_|_|_|_|_|_|_| Zero data detect ON/OFF NOTES: (1)- Manual sampling speed setting uses 3 bits. The third bit is in reg 05. See notes on register 00 for additional info on manual settings Register address: 02 (Control 3) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| Filter cutoff slope: fast/slow |_|_|_|_|_|_|x|_| MONO mode: left/right |_|_|_|_|_|x|_|_| Invert output pin level on zero detect |_|_|_|_|x|_|_|_| MONO/STEREO mode |_|_|_|x|_|_|_|_| DSD Data on clock falling/rising edge |_|x|_|_|_|_|_|_| DSD master clock frequency:512KHz/768KHz |x|_|_|_|_|_|_|_| PCM/DSD mode Register address: 03 (Left Channel Attenuation) 7 6 5 4 3 2 1 0 |x|x|x|x|x|x|x|x| Attenuation (1) NOTES: (1)- 256 levels, 0.5 dB each. 00=mute; ff=max volume Register address: 04 (Right Channel Attenuation) 7 6 5 4 3 2 1 0 |x|x|x|x|x|x|x|x| Attenuation (1) NOTES: (1)- 256 levels, 0.5 dB each. 00= mute; ff= max volume Register address: 05 (Control 4) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| Super Slow filter on/off |_|_|_|_|_|_|x|_| Bit 3 of the manual sampling speed setting (see reg 01) |_|x|_|_|_|_|_|_| Left channel phase invert ON/OFF |x|_|_|_|_|_|_|_| Right channel phase invert ON/OFF Register address: 06 (control 5) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| DSD bit 0 of sampling speed selection (bit 1 is in reg 9)(1) |_|_|_|_|_|_|x|_| DSD Mode: Direct/Convert to PCM (2) |_|_|_|_|x|_|_|_| DSD Automute release when Automute release is in "hold" |_|_|_|x|_|_|_|_| Automute release: Auto/hold (3) |_|_|x|_|_|_|_|_| Right Channel DSD flag when detecting full scale signal |_|x|_|_|_|_|_|_| Left Channel DSD flag when detecting full scale signal |x|_|_|_|_|_|_|_| DSD AutoMute: ON/OFF (4) NOTES: (1)- There is no facility for setting auto sample rate detection for DSD. The use must detect the incoming DSD sample speed and match the sampling speed. Will have to experiment to see what is the effect of sample speed mismatch. (2)- In DSD direct mode, the volume control and delta-sigma modulator are bypassed. In PCM mode, it converts to PCM and uses volume control block and delta-sigma modulator. DSD direct with a combination of the internal filter and simple output filter meets the filter specification of the SACD Scarlet Book. (3)- Automute condition disappears when data becomes under full scale (4)- Automute condition is when data is full scale Register address: 07 (Control 6) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| Synchronize ON/OFF (1) NOTES: (1) Synchronizes multiple DACs when used together in the same system. Read data sheet for more information. Register address: 08 (Control 7) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|x|x| Sound Quality Control Setting (1) NOTES: (1): Sound Control has 3 settings: "1", "2", "3". The AK4495 data sheet shows additional settings "4" and "5". These setting refer to the 5 different filters that are available in the DAC. They serve the same function as the filter selection bits specified in the other registers. What is unclear is which register takes precedence. Register address: 09 (Control 8) 7 6 5 4 3 2 1 0 |_|_|_|_|_|_|_|x| DSD bit 1 of sample speed selection (see also reg 5) |_|_|_|_|_|_|x|_| DSD filter selection when in DSD direct mode
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 GroundThe 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.
- RPi detects the sample rate of the clicked-to-play track.
- RPi has a way to indicate the sample rate (for example using GPIO pins).
- Microcontroller reads sample rate.
- 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]
Raspberry Pi version B+
Previously I wrote:
I had ordered a BBB for no other reason that it’s better looking than the Rpi 🙂
Well, no longer. I ordered the new version B+ because it is as good looking as the BeagleBone Black 🙂
Not really. The reason is because that there is a lot, lot more community development in the Pi than the Beagle. In fact if we just look at shipments, the Raspberry Pi sells almost 20 times the amount of BeableBone Black (over 3.8 million [link] vs 200,000 devices [link]). This is a huge advantage in the popularity front.
I had been a fan of the BeagleBone board [link] mainly because it is a higher performance board and had local storage. In addition (by design or by accident) the audio master clock uses an on-board 24.576 MHz clock from which it derives the frequencies for 48KHz sample rate material with integer division. There is also the capability of receiving the master clock from external sources and thus it is possible to feed it a higher quality 24.576 MHz and 22.5792 MHz clocks. There has been a clock board (and corresponding drivers) in the works since early this year, but nothing available yet as of this writing [link]
In contrast, there has been a much larger development effort in the RPi front as testified by the numerous I2S DAC boards that have become commercially available. Many of these companies are dedicated to building audio solutions first for the Raspberry Pi and then possible for other embedded platforms.
Here is a list of DAC boards available for the Raspberry Pi (versus none for the BeagleBone Black as of this writing)
| COMPANY | PRODUCT |
PRICE | DAC CHIP |
COMMENTS |
| G2 Labs | BerryNOS 1543 RED | $125 | Philips TDA1543 | Balanced design, discrete output stage, power supply |
| BerryNOS mini | $60 | Philips TDA1543 | Balanced design, discrete output stage | |
| HIFIBerry | HiFiBerry DAC | €25 | TI PCM5102A | |
| HiFiBerry DAC+ | €30 | TI PCM5122 | DAC volume control | |
| IQAudio | PiDAC | $38 | TI PCM5122 | DAC volume control |
| PiDAC+ | $42 | TI PCM5122 | DAC volume control, headphone amp | |
| Saparel | RaspiPlay3 | $40 | TI PCM5102A | From Serbia |
| RaspiPlay4 [link] | TBD | TI PCM5122 | DAC volume control, IR remote | |
| Audiophonics | I-Sabre DAC | €25 | ESS ES9023 | |
| I-Sabre DAC+ | €43 | ESS ES9023 | ||
| Element 14 | Wolfson Audio Card | $35 | Wolfson WM5102 | Available through resellers. WM5102 is a complete audio system. The board implements line-in, line-out, speaker and headphone output and mic input. The board also includes a WM8804 providing SPDIF input and output, a digital microphone and expansion header for other Wolfson devices |
| TekDevice | DACBerry2+ | $45 | TI PCM5102A | |
| DACBerry3+ | $51 | ESS ES9023 | ||
| HIFImeDIY | ES9023 DAC | $19 | ESS ES9023 | Lowest price! |
| DurioSound | DurioSound | $45 | TI PCM5102A | Has ultra low noise regulator (TPS7a47) |
| DurioSound Pro | $70 | TI PCM5102A | Has ultra low noise regulator (TPS7a47) and Local Power Supply |
Notes:
- Notice that the DAC chips used are the ones that can cope without a Master Clock. RPi I2S does not Master Clock, so the DACs synch on bitclock and generate their own master clock.
- Products using PCM 5122 can use the DAC’s internal volume control and therefore can be connected directly to an amplifier.
- There are companies such as diyinhk and curryman that are not listed because they do not specifically make DAC boards that conform to the RPi footprint but are fully functional as I2S DACs. Any I2S DAC that does not require master clock will work.
My Favorite ones are the HIFIBerry DAC+ and the IQAudio PiDAC+, both based on the PCM 5122 with “hardware” volume control (meaning using the volume control in the DAC itself)
[link]
[link]
WHAT IS NEW IN THE B+
In the two years since we launched the current Raspberry Pi Model B, we’ve often talked about our intention to do one more hardware revision to incorporate the numerous small improvements people have been asking for. This isn’t a “Raspberry Pi 2″, but rather the final evolution of the original Raspberry Pi. Today, I’m very pleased to be able to announce the immediate availability, at $35 – it’s still the same price, of what we’re calling the Raspberry Pi Model B+. [link]
There are a million reviews on the Raspberry Pi. Here is one more but with a slant towards diyaudio…
New Layout (and more I/O pins)
Notice that the I2S pins are right next to a GND pin. This is particularly good as you can easily use twisted pairs (for noise immunity) when connecting to a DAC
List of integrated circuits [link]
| Label | Device | Description |
| U1 | BCM2835 | SoC comprising ARM Processing core and Video Core. Data Sheet |
| U2 | LAN9514 | 4 USB 2.0 Hub and 10/100 Ethernet controller. Data Sheet |
| U3 | PAM2306AYPKE | Dual DC-DC Switching converter. Data Sheet |
| U4 | APX803-46SAG | Brownout detector (reset generator) Data Sheet |
| U5 | AP7115-25SEG | 150 mA Linear Regulator. 50 uV noise (Video DAC) Data Sheet |
| U6 | N.U. | |
| U7 | N.U. | |
| U8 | ESD5384 | ESD protection for HDMI. Data Sheet |
| U9 | AP2331W | Current limited switch (for HDMI hot plug) Data Sheet |
| U10 | AP7115-25SEG | 150 mA Linear Regulator. 50 uV noise. (PWM Audio Driver supply) Data Sheet |
| U11 | NC7WZ16 | Ultra High Speed dual buffer. (PWM Driver) Data Sheet |
| U12 | N.U. | |
| U13 | AP2553W6 | USB current limited power switch (for hot plug). Data Sheet |
| U14 | DMMT5401 | Matched PNP transistors. Data Sheet |
Board schematic here: [link]
The audio jack is also a composite AV jack
More USB Ports
New USB/Network Chip (to support the 4 USB ports)
The USB powerchain has a proper limiting switch and will not brown out the board if USB devices are plugged in when powered (or even if they try to take too much current or there is a fault like a power short). Default allowed USB current across 4 ports is 600mA, but can be increased to 1.2A via a config.txt parameter if a good quality 2A PSU is used. I have tried a few different USB hard disks and they all power fine directly from the Pi at the 1.2A setting. [link]
To increase power to 1.2A you add the following line in /boot/config.txt[link]
max_usb_current=1 (newer software)
safe_mode_gpio=4 (older software)
The 5V for the USB ports is provided directly by the 5V of the input supply. The schematic below shows the 5V sourced from Power In. There is a 2A fuse a diode-like low-drop polarity protection circuit and an over-voltage zener.
Therefore a better quality power supply is required. Here is an excellent post on choosing and evaluating 5V charger/supply [link]
I like the Orico DCX-2U. It has two USB outputs: 1×2.4A, 1×1.5A. The 2.4A output is plenty for a “fully loaded” RPi
High Efficiency Switching Supply (power consumption is reduced by between 0.5W and 1W)
The DC-DC Switching supply is the PAM2306AYPKE. This device supplies the 3.3v and 1.8v supplies. The switching frequency is 1.5MHz (which can easily removed by the LC filters on the outputs).
MicroSD Card Slot
There are many theories as to why the SD card was replaced with the micro SD card. I think it is probably lower cost.
BETTER ANALOG AUDIO
According to the people from Raspberry Pi, the audio in the B+ model has been improved. The audio circuit (AUDIO out) incorporates a dedicated low-noise power supply (the input to this power supply is the external 5V supply). According to this comment [link]:
The B+ does not use use a switching regulator for its PWM driver, that would indeed be a bad design choice, instead it uses the AP7115-25SEG [link] low drop regulator with high power supply rejection ratio. It creates a noise free 2.5V for the NC7WZ16 PWM driver, the output of which is attenuated and filtered with two 100 Ohm resistors, and a 100 nF capacitor, so the output is 50 Ohm, and can reach 1.25Volt p/p.
U10 is the linear regulator and U11 is the “PWM Driver”
Whether this audio is “better” or not, it does not concern us. Take a look at this post [link].
WHAT’S THE SAME?
Same SoC (Same ARM processor and GPU and 512MB of RAM)
Unlike the BeagleBone Black, there is no local memory for storage. The s/w runs out of the microSD card.
Same external 19.2 MHz crystal
R-2R DAC For The REST of US
A MOST INTERESTING DIY PROJECT IN A LONG TIME
A Discrete R-2R Sign Magnitude 24 bit 384 Khz DAC [link].
The DAC Module includes all local power supplies, a programmable low jitter clock, Micro-controller and balanced output buffer. It is implemented on a 4-layer PCB. The board size is 3.2″ x 5.8″ (81 x 147 mm).
As the industry migrated from R2R topologies to Sigma-Delta in their quest for higher bit-depth, higher performance (and cost management), present implementations of R2R DACs are pretty much hand-crafted commanding a high premium.
As the author states:
“I believe that the sound quality will be the absolute best, better than any Delta Sigma DAC, in class with discrete DAC’s from totaldac and msb technology. And for way way less cost :-)”
For the rest of us with limited resources wanting to experience a ladder DAC, this is the DAC to have.
An excerpt from the PCM1704 [link] datasheet expunds the good points of a ladder DAC:
Digital audio systems have traditionally used laser-trimmed, current-source DACs in order to achieve sufficient accuracy.
However, even the best of these suffer from potential low-level non-linearity due to errors in the major carry bipolar zero transition. Current systems have turned to oversampling data converters, such as the popular delta-sigma architectures, to correct the linearity problems. This is done, however, at the expense of signal-to-noise performance, and the noise shaping techniques utilized by these converters creates a considerable amount of out-of-band noise. If the outputs are not properly filtered, dynamic performance of the overall system will be adversely effected.
The PCM1704 employs an innovative architecture which combines the advantages of traditional DACs (e.g., excellent full-scale performance, high signal-to-noise ratio, and ease of use) with superior low-level performance.
Granted, that was circa 1999. Since then the Sigma-Delta camp has made great strides. Even so, R2R DACs have not lost their appeal as witnessed by the interest in this project and the current commercial offerings.
TARGET PRICE
The DAC module is not yet available for sale. The target price is US$240 with 0.02% resistors. This is a steal considering how much other R2R implementations cost.
ADVANCING THE STATE OF THE ART
The last commercially available R2R DAC chips were the PCM1704 [link] and the AD1865 [link]. They have been out of production for a long time but still available for purchase for example here [link] and here [link].
Here is a table comparing selected performance numbers and features as described in the data sheets and by the author in the diyaudio discussion thread.
- The PCM1704 is typically used withe a companion chip, the DF1704 [link].
- The AD1865 is also used with a companion filter chip such as the Sony CXD1244S [cxd1244s]
| Parameter | Seokris R2R |
PCM1704+DF1704 | AD1865+Digital Filter |
| Max Input Sample Size | 24bit | 24bit | 18bit |
| Max Input Sample Rate | 382KHz | 96KHz | 44KHz |
| Max Resolution | 28bit (1) | 24bit | 18bit |
| Inputs (2) | 1x Isolated I2S, 3x SPDIF/TOSLINK/AES/EBU [link]; future DSD upgrade | Serial only (DF1704: LJ, I2S) | Serial only through the digital filter chip |
| S/W Interface | Serial (Not I2C) | Serial (Not I2C) | Depends on filter chip |
| Oversampling Filter | On-board built-in and user defined (3) | Sharp, Slow roll-off (DF1704) | Needs External Filter |
| Channels | 2 – Stereo | PCM1704 is single channel, so DF1704+2XPCM1704 | 2 – Stereo |
| Jitter Reduction | Re-clocking input data through a FIFO Buffer (similar in design to Ian’s FIFO [link]). Uses a low jitter (0.8 psec RMS) Si514 programmable clock [link] which drives the LVC595 shift registers after clock division in the FPGA (Si514 -> FPGA divider -> LVC595) | None | None |
| Output | “Raw” single-ended voltage output (1.4V RMS, 1.25 Kohm) or buffered balanced voltage output using TI LME49710 + LME49724 [link] | Single-ended current output | Single-ended current output or buffered single-ended voltage output |
| Jitter Reduction | FIFO Buffer and reclock with low jitter clock | None | None |
| THD+N (0db) | 0.0063% .05% resistors (Module measurement) | 0.0008% K-Grade (PCM1704 spec) | 0.003% J/K Grade (AD1865 spec) |
| THD+N (-20db) | – | 0.006% K-Grade (PCM1704 spec) | 0.01% J/K Grade (AD1865 spec) |
| THD+N (-60db) | 0.37% .05% resistors (Module measurement) | – | 1% J/K Grade (AD1865 spec) |
| SNR | 126 dB (Link) | 120 dB | 110 dB |
Notes
(1) The Soekris R2R implements 28 bits of internal resolution in order to provide sufficient headroom to allow for a “perfect digital volume control. At -72 db volume you still have 16 bit resolution with perfect linearity” [link].
(2) The PCM1704 and AD1865 are NOS ladder DACs expecting an input stream from an external filter device such as the DF1704 [link]. Therefore they typically cannot accept and I2S input format. The input format for those chips consists of a clock signal, data signal and data latch signal. More information can be found in Ian’s “I2S to PCM” board project [link].
(3) The oversampling filter is implemented in the on-board Spartan-6 LX16 FPGA. It has 15K logic cells and can be configured as having 8 full high resolution MAC’s by using its 32 DSP48A1 MAC blocks in groups of 4 allowing them to do 35 x 35 bit multiplications plus 70 bit summers. Two of these hig-res MACs can be used for the first 2 most critical oversampling FIR filters; running them at just 49.152 Mhz makes space for 1024 coefficients if needed, then 2 more for the rest of the FIR filters. The rest for other functions, like de-emphasis, volume control and digital crossover filters… [link]. The user can use generate the filter coefficients and upload them to the FPGA [link]
Filter tools:
Here is a photo showing some of the details disclosed in the diyaudio thread. The LVC595A [link] are 8-bit shift registers: 7 bits on one side of the chip and the 8th bit on the other side of the chip. In this implementation the 8th bit is not used in order to optimize the layout (only using the outputs on one side of the chip) as can be seen in the photo.
The capacitor in the low pass filter (C142 in the photo) is the only capacitor in the signal path. It is a high quality C0G/NP0 ceramic. Those wishing for “higher quality” can replace/bypass with a film capacitor.
ISOLATED I2S and SPDIF INPUTS
The input is isolated with (what appears to be) TI ISO7420FE digital galvanic isolators [link]. There are 3 identical isolators resulting in 6 input lines. I think these support one I2S input and 3x SPDIF/TOSLINK/AES/EBU (I don’t know if the SPDIF lines are isolated, but there is no need for 6 isolated inputs if only the I2S is isolated). More info on isolators here [link]. Seems everyone has their favorite isolation device. Of the 4 different vendors I have surveyed, they have all been used by different audio diy implementers.
The TI ISO7420x and ISO7421x provide galvanic isolation up to 2500 V RMS for 1 minute per UL and 4242 V PK per VDE. These devices have two isolated channels. Each channel has a logic input and output buffer separated by a silicon dioxide (SiO 2 ) insulation barrier.
Built-in galvanic isolation at the input is a great idea. This gives the capability to completely isolate noise disturbance is coming from the source, including isolating ground, and since here is a FIFO reclocking stage afterwards, there is no need to worry about the small added jitter (100-200 psec RMS) that these devices would add to the data.
(update [link]) There will be two AES/Spdif inputs:
- Balanced into LVDS Receiver, can be connected directly to transformer and can be run single ended for SPDIF Coax, just a capacitor and two resistors needed when single ended 75R. To keep it isolated I recommend to always use a transformer for AES Balanced and SPDIF Single Ended inputs.
- 3.3V CMOS level input, can be connected directly to SPDIF Optical Toslink receiver.
Selection between I2S and AES/SPDIF sources can be automatic or manual with two pins that can be connected directly to a control switch. For more sources you can also just switch the inputs.
JITTER REDUCTION
A notable feature of this DAC module is the reclocking of the incoming. The design is similar in principle to Ian’s FIFO reclocker, The data is received into a configurable FIFO and then it is reclocked with a lower jitter clock.
However, Ian’s reclocker is designed for ultimate performance, whereas this reclocker is designed specifically for the DAC module and therefore matched to the requirements of the entire system (meaning, I think, the best consideration for jitter performance, cost and part count).
Here are the main differences between the two:
Ian’s FIFO reclocker
- Clock is Si570 which is the best programmable clock from Silicon Labs (.3 psec RMS jitter) [link]
- Clock drives the low jitter shift registers through a clock-fanout [link]. The jitter in the fan-out device is in the fsec range
Here is the clock board in Ian’s reclocker: the Si570 is used to clock the shift registers directly. The clock connects to a fan-out device (the chip next to the clock) and separate clock lines drive the 3 shift registers in the middle of the board.
R2R Module reclocker
- Clock is Si514 is the lower grade of programmable clocks from Silicon Labs (.8 psec RMS jitter) [link]. This is used instead of the Si570 because of power consumption (lower consumption for the Si514)
- Clock signal is transmitted through the FPGA for clock division and then to the shift registers. The added jitter in the FPGA is in the psec range. More details on the jitter through the FPGA here [link]
Here is the Si514 feeding its clock to the FPGA. The FPGA supplies the clock to the shift registers.
However, the reclocked signal in the R2R module feeds straight through the resistor ladder avoiding “several layers” of electronics as compared to a conventional implementation where the reclocked signal feeds the I2S receiver, the internal filters and other electronics of DAC chip. Internally, these “several layers” of electronics add jitter to the signal before arriving to the D/A conversion stage.
In the end, the actual jitter as seen by the resistor ladder is the cumulative jitter consisting of following components
- Clock intrinsic jitter (0.8 psec RMS)
- Jitter added by the FPGA (I think in the order of 10s psec RMS based on datasheet numbers)
- Jitter added by the shift registers in the psec order based on general data on shift registers
10s of psec RMS jitter at the resistor ladder is pretty darn good in my opinion.
Further details [link]
The details of my clocking/FIFO:
Ian’s FIFO use a fixed clock, and therefore use a large buffer to take up the difference between incoming and outgoing clock. That add a large delay, which doesn’t matter for simple audio applications but are undesirable in a number of applications, like home theater or live music.
I use a much shorter FIFO, selectable down to 1 mS, and instead adjust the outgoing clock to match the incoming clock frequency as needed, being I2S or SPDIF. The Si514 oscillator used is very low jitter and digitally programmable with a resolution of 0.026 ppb (parts per billion, not million…). It also have the feature that reprogramming inside +-1000 ppm is glitchless, ie the clock adjust very nicely to small changes.
ON-BOARD MICROPROCESSOR
The onboard microprocessor is the STM32F030 uC [link]. It is responsible for:
- Measure input clock and program the Si514 programmable clock as needed
- Initially, volume control by using a potentiometer
- More features later since this is a general purpose uC
The specific device is the 32 pin device of the family with 16 general I/O pins. I believe some of the I/O pins are available through J1
POWER SECTION
The following details have been shared about the power section of the DAC ([link], [link], [link])
- Designed to be powered by a single dual 7-8V, 5W transformer. Can also take an external +/- 7-15V DC supply. Filter capacitors are Nichicon 820uF 16V CL series
- “The LME output buffers are powered via an additional large RC filter after the main capacitors, no active regulators. With a typical PSRR of 125 db I didn’t worry much about 100/120 hz ripple, only worried about higher frequency noise on the power rails….”
- A DC-DC converter (switch mode) provides the 1.2V for the FPGA core. Every other supply is low noise linear [link]
- The most critical supply is the +/- 4V reference for the resistor ladder. This is generated by a “two step, first to +- 5V, then to +-4V by precision low noise medium current opamps”; “-4V reference is sent though an inverter with 0.01% resistors generating the +4 reference”. The references are further “filtered and buffered for each rail and channel”.
- Negative voltage is required for the output opamps and other parts of the circuit [link]
Here is a picture of the main supply section. The description is my best guess based on the information provided. I believe the digital section is powered by a DC-DC converter-regulator, except for the clock which has its own regulator.
CUSTOM FILTERS AND DIGITAL CROSSOVER
I think the ability for user-defined custom digital filters is a BIG feature for this DAC. In addition to the traditional DAC filters, one can load filters that implement crossover functions.
One of my frustrations with the ESS DAC is that I have not been able to take advantage of the custom filter facility. I am able to program everything else, except for the custom filters. Even though some claim that this feature works fine, I have not encountered any diy implementation and only one or two commercial implementations. Whether due to my own ignorance or to other factors (such as lacking documentation), fact is that there are no publicly disclosed diy successes of having implemented custom filters in the ESS DACs.
With crossover filters, there is finally a BIT PERFECT high quality DAC + digital crossover solution. More specifically, current digital crossovers if used with an external DAC of choice would add additional A/D or D/A conversions plus asynchronous sample rate conversion. Imagine a more “straight wire” implementation.
(Update [link]):
First firmware release will NOT support digital crossovers, although there will be 14 available biquads, already tested in order to support de-emphasis on SPDIF inputs. As somebody already noted, there is issue of syncronization…. I have a couple of ideas how to connect multiple boards together, but I don’t have time to implement and test before shipping the first batch. But as I already said, all firmware on the board is upgradable though a std PC serial port, I will implement it soon as my big speakers are already designed for electronic crossover use….
ES9018K2M Code Fully Tested
A new version of the code has been posted in the CODE tab [link].
This version has been fully tested with an Amanero USB interface [link] connected to the DIYINHK DAC board with an 80 MHz clock. Both PCM and DSD files of various sample rates were used together with foobar [link]
FEATURES
READ THE CODE CUSTOMIZATION SECTION
Make the proper adjustment for your specific implementation in the code.
/******************* Code Customization Section *********************/ /* First: Choose the clock frequency you have and comment the other */ #define USE80MHZ //#define USE100MHZ /* Second: Choose stereo or mono | CONFIGURATION | #define DUALMONO | #define STEREO | |---------------------|------------------|------------------| | Dual mono | un-comment | comment | | Stereo | comment | un-comment | |---------------------|------------------|------------------| */ #define STEREO //#define DUALMONO /* Third, optionally choose the number of inputs. 6 is the max without modifying the code. You could lower the number of input choices here. for example if you only want to see 2 choices, modify the code like this: #define ICHO 2 */ #define ICHO 6 /* Fourth, optionally change the name of the inputs. Keep 6 characters Use blanks if necessary. If you use less number of inputs, only the top ones matter. */ char no0[] = "INPT-A"; char no1[] = "INPT-B"; char no2[] = "INPT-C"; char no3[] = "INPT-D"; char no4[] = "INPT-E"; char no5[] = "INPT-F"; /* These inputs choices can be virtual or real. In the ES9018 there were 8 data lines. One could simultanously connect one I2S/DSD input plus 3 additional SPDIF input (thus 4 physical inputs). In the ES9018K2M there are two additional input lines for SPDIF so one can potentially connect one I2S/DSD input plus 2 additional SPDIF inputs.In addition one could choose different parameters -such as the DPLL bandwidh or filter selection- */ /* Fifth, adjust the interrupt routine to match your rotary encoder by adjusting the mode parameter in the following routine (search for it in the code): "attachInterrupt(0, rotEncoder, LOW);" The mode parameter defines when the interrupt should be triggered: LOW to trigger the interrupt whenever the pin is low, CHANGE to trigger the interrupt whenever the pin changes value RISING to trigger when the pin goes from low to high, FALLING for when the pin goes from high to low. You can also read the following link: https://hifiduino.wordpress.com/2011/09/12/problems-with-rotary-encoders/ */ /***************** End Code Customization Section *******************/
This code should also work with syllable’s DIY DAC [link] which is also described in this builders thread [link]
iBOX
Got an engineering sample of this new embedded board solution from iTead Studio. It is based on the Allwinner Technology A20 Dual Core SoC (The same processor as the Cubietruck board). iBox is being crowd-funded at indiegogo [link]. At $70 including power supply and case is an incredible deal.
The iBox is an example implementation of the modular approach that iTead is developing. A “system” can be configured with a “core board” and a “baseboard”. Thus iBox is a core board plus a baseboard and plus a case.
The case is made of gray-anodized aluminum with a plastic top and a steel bottom. (I added some rubber feet)
Here is compared to the size of a uSD card
Front side: uSD card reader, status LED and IR receiver
Side: Multi-function expansion connector
Back side: Peripheral connectors
The Core board
The A20 core board [link] is designed as a “computer on a module” and consists of
The core board is designed as a bare minimum computing module that breaks out most of the I/O pins and buses through two rows of pin headers. The approach also is to “standardize” the pin-header form-factor to allow mixing and matching with baseboards in order to suit different requirements. In addition, this approach provides an upgrade path to newer or different processors.
A20 SoC and DDR3 RAM (The GT chips, each 512MB). The 4 GB Flash should be in the back side of the board.
The Power Management Unit, AXP209
24MHz oscillator
Detail Connection to baseboard
iBox Baseboard
The baseboard in iBox is designed to provide peripheral interfaces and connect to a core board. The iBox baseboard is one of different baseboards that iTead is developing and as one of the first implementations, it aims at wide appeal by providing the most common I/O interfaces.
USB Hub: GL850G Hub
Ethernet Interface: Realtek RTL8201CP
The board has a 3 Amp switching regulator, the MP2307 set at 5V. The input range of the regulators is 4.75V to 23V.
uSD Card reader, IR receiver and LED indicator
Multi function expansion connector
USB and HDMI connectors
SPDIF Toslink optical connector, Ethernet and power connector. The bundle supply is rated a 9V, 2 Amp
Summary of iBox baseboard interfaces and connectors:
- Power connector
- 5V regulator (MP2307)
- Four 2.0 USB ports (Integrated GL850G Hub)
- HDMI port,
- Ethernet interface (Integrated Realtek RTL8201CP 100M transceiver)
- SPDIF optical (Digital Audio Output)
- U-boot button (Universal Bootloader. U-boot to embedded boards is like BIOS to PC motherboards)
- uSD care reader
- IR receiver (for remote control)
- Status LED indicators
- 32-pin multi-function expansion interface providing the most common interfaces
- Video output
- Serial Interface
- Debug interface
- I2C
- SPI
- SATA Interface
- Analog audio In
- Headphone Out
In fact there will be an expansion board [link] available with SATA connectors plus other connectors
AUDIO
Since this site is dedicated to audio, we will focus a bit on the audio capabilities of iBox
ANALOG AUDIO
According to the datasheet, The A20 has the following built-in audio features:
Analog Output
- DAC
- 16bit, 24-bit data
- 44.1KHz, 48KHz, 96KHz and 192KHz sample rate
- 100 db SNR
- Analog/Digital volume control (62 steps)
- Stereo headphone amplifier (capless). dedicated headphone output
Analog Input
- ADC: 24-bit, 8KHz to 48KHz, 96 db SNR
- Line-in Stereo or one differential
- Two Microphone input
- Stereo FM input
Here is the analog/headphone output diagram:
DIGITAL AUDIO
Spdif
The iBox has a built-in SPDIF/Toslink connector. According to these discussions [link], the SPDIF output supports:
- 16bit data
- Up to 192KHz sample rate
I2S
- Resolution: 16bit, 20bit and 24bit
- Sample rates: 8KHz to 192 KHz
- Format: I2S, Left Justified, Right Justified
- Frame (BLCK): 16bit, 20bit, 24bit and 32bit
I’ve previously described the I2S capabilities of the A20 processor here [link]. The A20 datasheet (p.20) [link] specifies that the chip supports up to 8 channels of I2S output (DO0 to DO3 represent the 4 stereo channels of I2S data).
I2S support in the core board
In the Itead A20 core board pin schematic [link] we can see that the I2S pins are available and connected to the pin headers (PB5 to PB11):
I2S support in the baseboard
Looking at the schematic of the iBox base board, pins PB5-PB11 are not connected to the expansion header. However, PB5-PB11 pins are available on the underside of the base board (they are just soldered without connecting to anything) and can be easily tapped.
SOFTWARE
I shall get familiar with the software environment and report shortly in the next post…
ALLWINNER TECHNOLOGY, THE COMPANY
The A20 SoC was announced about a year ago. I have to admit, I had never heard of this company. A bit of digging uncovered that this company is fast becoming a dominant player in the SoC market:
You may never have heard of Allwinner but they are huge and as of CES now have an 8-core tablet part on the market. With the release of the A80 SoC and the OptimusBoard that SemiAccurate used, the company is well positioned for the mainstream tablet market in 2014.
Allwinner rarely makes the headlines because they don’t make bleeding edge products that go in to high-end phones and tablets, instead they make mainstream SoCs that go in to high volume tablets. This mid-range market has decent margins, huge volumes, and since they don’t target phones directly there are no radio hassles and regulation to deal with. How big is Allwinner? Huge. Continue reading: [link]
The most interesting part of this company is their announcement to join Linaro’s newly formed Digital Home market segment group as a founding member together with media behemoth Comcast (and others). This means that there will be more video and audio applications coming our way.
Linaro Ltd, the not-for-profit engineering organization developing open source software for the ARM® architecture, today at Linaro Connect Asia 2014 (LCA14) in Macau announced* that …
Allwinner Technology is a founding member of a new market segment group being formed in Linaro to focus on the Digital Home market. This group will be the third Linaro segment group, following the formation of the Linaro Enterprise Group (LEG), focused on ARM servers, and the Linaro Networking Group (LNG) focused on the networking equipment market space.
OS SUPPORT
The list from iTead should work as is. Others are compatible with the A20 SoC, but may require additional work to support the peripheral components.
REFERENCE
- iTead Documentation and Download Repository [link]
- Audiophile bit-perfect with the A10 [link]
- CNX Software Blog. Developments on embedded computing, including news on Linaro [link]
- Review of A20 built-in DAC and headphone output [link]
BEAGLEBONE BLACK: NAVIGATING THE AUDIO MAZE
It is almost ironic that the quest for a “perfect audio appliance” which led us to the “simpler”, low power (the BBB consumes less than 5W) and light-weight world of embedded Linux, has also led us to the incredibly complex world of Linux audio.
Because of its long evolution, long list of requirements from both sound professionals and consumers, and open development environment, many audio subsystems have flourished, each having their own set of unique features, duplicating features from each other, providing interfaces to as many applications (even legacy applications) as possible and attempting to interfaces to each other.
Here is a depiction of Linux audio (circa 2008) [link]:
According to TuxRadar [link],
There’s a problem with the state of Linux audio, and it’s not that it doesn’t always work. The issue is that it’s overcomplicated. This soon becomes evident if you sit down with a piece of paper and try to draw the relationships between the technologies involved with taking audio from a music file to your speakers: the diagram soon turns into a plate of knotted spaghetti. This is a failure because there’s nothing intrinsically more complicated about audio than any other technology. It enters your Linux box at one point and leaves at another.
To and audio application, Linux audio provides several audio subsystems through which audio can be channeled: ALSA, PulseAudio, Jackd, OSS and others. An application can use anyone of these subsystems and in fact they do in order to provide wide appeal and compatibility.
Here is a very simplified and high diagram describing the different audio subsystems and their relationship [link]:
And application can literally take any route through the different components in order to arrive at the hardware. An application can use Alsa, routed through Jack and back to Alsa; or it can use PulseAudio to OSS or Alsa all the way. Audio applications such as MPD can use either ALSA, PureAudio or OSS in order to appeal to a wider audience and provide compatibility to new, old and in-between versions and flavors of Linux.
FOCUS ON ALSA
In our quest for bit-perfect audio, A reasonable approach to simplify the audio path is by minimizing the number of components through which the audio stream can possibly travel.
A practical way to do this is to direct the application to use a single audio subsystem. In our case, restricting to ALSA looks like a good option since it is already included in the Debian BBB release. (At least PulseAudio and Jack are are installed when installing MPD)
This site [link] also has a good overview of the different sound subsystems in Linux. A graphical description of ALSA is as follows:
The key message here is that ALSA looks like a “simple” interface between an audio application and the hardware and that there is a Mixer (Sound Mixing) outside the Kernel that CAN can potentially be bypassed. And indeed it can be bypassed:
A sound developer who wishes to output sound in their application can take any of the following routes with ALSA:
- Output using ALSA API directly to ALSA’s Kernel API (when sound mixing is disabled)
- Output using ALSA API to sound mixer, which outputs to ALSA’s Kernel API (when sound mixing is enabled)
- Output using OSS version 3 API directly to ALSA’s Kernel API
- Output using a wrapper API which outputs using any of the above 3 methods
A further simplification is to restrict the use of ALSA through the ALSA API (a more modern API) and avoid using the OSS v3 API (Legacy API). This may not be an issue as modern applications do not have a need to use the older OSS v3 interface.
MPD (MUSIC PLAYER DAEMON)
Since Volumio and RuneAudio are using MPD, It is a good idea to select MPD and figure out how it works. MPD simply runs in the background playing music from its playlist. Client programs communicate with MPD to manipulate playback, the playlist, and the database. [link]
Configuring MPD to use ALSA
The mpd configuration file is at /etc/mpd.conf. (The default configuration for mpd -as installed for debian, uses ALSA.)
The MPD documentation [link] indicates that it is capable of outputting to 15 plugins (ALSA, PulseAudio, OSS, etc). The configuration file allow the selection of the output plugin. Here is the example for selecting ALSA as the output of MPD:
To configure an audio output manually, add an audio_output block to mpd.conf:
audio_output {
type "alsa"
name "my ALSA device"
device "hw:0"
}
Further, the configuration allows us to disable and bypass any mixing/resampling of the audio data. I’ve highlighted in red the important parameters.
The following table lists the audio_output options valid for all plugins:
Additional ALSA specific fields can be added according to this table (ALSA uses libasound)
| Setting | Description |
|---|---|
device NAME |
Sets the device which should be used. This can be any valid ALSA device name. The default value is “default”, which makes libasound choose a device. It is recommended to use a “hw” or “plughw” device, because otherwise, libasound automatically enables “dmix”, which has major disadvantages (fixed sample rate, poor resampler, …).Note: the default device can be set in the ALSA configuration file. The default device can be set to “hw” type and thus bypassing “dmix” the ALSA mixer. |
use_mmap yes|no |
If set to yes, then libasound will try to use memory mapped I/O. Here is an example using this parameter [link]: “yes” # Minor speed improvement, should work with all modern cards |
buffer_time US |
Sets the device’s buffer time in microseconds. Don’t change unless you know what you’re doing. Note: etc/mpd.conf states: MPD Internal Buffering: ****** This setting adjusts the size of internal decoded audio buffering. Changing this may have undesired effects. Don’t change this if you don’t know what you are doing: audio_buffer_size “2048”. ******This setting controls the percentage of the buffer which is filled before beginning to play. Increasing this reduces the chance of audio file skipping at the cost of increased time prior to audio playback: buffer_before_play “10%” |
period_time US |
Sets the device’s period time in microseconds. Don’t change unless you really know what you’re doing. |
auto_resample yes|no |
If set to no, then libasound will not attempt to resample, handing the responsibility over to MPD. It is recommended to let MPD resample (with libsamplerate), because ALSA is quite poor at doing so. |
auto_channels yes|no |
If set to no, then libasound will not attempt to convert between different channel numbers. |
auto_format yes|no |
If set to no, then libasound will not attempt to convert between different sample formats (16 bit, 24 bit, floating point, …). |
dsd_usb yes|no |
If set to yes, then DSD over USB according to the proposed standard by dCS and others is enabled. This wraps DSD samples in fake 24 bit PCM, and is understood by some DSD capable products, but may be harmful to other hardware. Therefore, the default is no and you can enable the option at your own risk. |
Thus in the MPD configuration we can:
- Specify ALSA as output plugin
- Specify that no mixer should be used in audio output plugin
- Specify that no volume adjustment be applied
- Further disable “dmix” the ALSA mixer (#2 may do the same thing. But you never know…)
- Further disable resampling in the output (dmix?)
- Optionally enable DSD over USB
Here is a guide on setting up MPD that will illustrate some of the parameters discussed above [link].
Configuring sample rate converter in MPD
Now that we’ve taken cared of the output plugin configuration, we need to ensure that other MPD plugins do not do sample rater conversion and/or mixing.
MPD can use one of the following sample rate converter:
- Internal (built in into MPD, low overhead, low quality)
- Sox (provided by libsoxr [link])
- Secret Rabbit Code (provided by libsamplerate [link])
Both libsoxr and libsamplerate can be compiled into MPD so they may be already available in the MPD package. After installing the package mpd in Debian/BBB further request for libsamplerate and libsoxr fails to locate these libraries, likely indicating that these have already been compiled into mpd (I am using “mpd” and “MPD” interchangeably).
SRC (libsamplerate) provides a small set of converters to allow quality to be traded off against computation cost. The current best converter provides a signal-to-noise ratio of 145dB with -3dB passband extending from DC to 96% of the theoretical best bandwidth for a given pair of input and output sample rates. [link] -The MPD documentation lists 97 db SNR [link]. Not sure how the two figures are related.
The MPD documentation says:
The setting samplerate_converter controls how MPD shall resample music.
If MPD has been compiled with libsamplerate support, this setting specifies the sample rate converter to use. Possible values can be found in the mpd.conf man page or the libsamplerate documentation. By default, this is setting is disabled.
Possible values:
| Value | Description |
|---|---|
“internal“ |
The internal resampler. Low CPU usage, but very poor quality. |
“soxr very high“ |
Use libsoxr with “Very High Quality” setting. |
“soxr high” or “soxr“ |
Use libsoxr with “High Quality” setting. |
“soxr medium“ |
Use libsoxr with “Medium Quality” setting. |
“soxr low“ |
Use libsoxr with “Low Quality” setting. |
“soxr quick“ |
Use libsoxr with “Quick” setting. |
“Best Sinc Interpolator” or “0“ |
libsamplerate: Band limited sinc interpolation, best quality, 97dB SNR, 96% BW. |
“Medium Sinc Interpolator” or “1“ |
libsamplerate: Band limited sinc interpolation, medium quality, 97dB SNR, 90% BW. |
“Fastest Sinc Interpolator” or “2“ |
libsamplerate: Band limited sinc interpolation, fastest, 97dB SNR, 80% BW. |
“ZOH Sinc Interpolator” or “3“ |
libsamplerate: Zero order hold interpolator, very fast, very poor quality with audible distortions. |
“Linear Interpolator” or “4“ |
libsamplerate: Linear interpolator, very fast, poor quality. |
It appears that there is no “off” setting, so that MPD will always attempt to resample audio in order to match the capabilities of the downstream components. There doesn’t seem to be a way to remove all the resamplers even by removing libsamplerate and libsoxr because there is always the internal resampler of MPD. In the case of the mpd package for debian, it is likely that libsamplerate and libsoxr have been compiled with mpd, so removal is not possible.
It is also reasonable to assume that if the “samplerate_converter” setting is not used in the config file (the default condition), a default sample rate conversion method would be applied.
We already have a way to disable “dmix” in ALSA which defaults to 48KHz, so there is no need for MPD to resample to 48KHz to meet the requirements of dmix. The only remaining sample rate requirement is the capability of the hardware. It is therefore reasonable to assume that if the hardware is capable to supporting the sample rate of the audio file, then no resampling would be performed.
CONFIGURING ALSA
According to these sites [link]. [link]
There are 3 configurations files that are read every time an ALSA device is opened:
- Default configuration file (comes with ALSA and should not be changed): /usr/share/alsa/alsa.conf
- System wide configuration file (optional): /etc/asound.conf
- User configuration file (optional, residing in the users home directory): $HOME/.asoundrc
There is no need to write a configuration file since the default is always present. However, for our purpose we want to ensure that the data is sent to device without any mixing or resampling by ALSA
Recall from the ALSA-specific settings above:
It is recommended to use a “hw” or “plughw” device, because otherwise, libasound automatically enables “dmix”
Type=hw
Thus we wish to define a “hw” device. For our purpose we create a /etc/asound.conf file with the following entry:
pcm.!default {
type hw
card 0
}
The exclamation sign causes the previous definition of pcm.default to be overridden (so we don’t have to worry about the default configuration file /usr/share/alsa/alsa.conf).”card 0″ is the audio device we wish to use. It could be “card 1” or other. See below to determine what to use. “type hw” is used as recommended.
If sample rate conversion is needed, we can use the “plug” type
Type=plug
Use the following entry in /etc/asound.conf
pcm.!default {
type plug
slave.pcm {
type hw
card 0
}
}
EXPLORING THE AUDIO COMPONENTS IN DEBIAN/BBB (KNOWN TO ALSA)
I used this guide [link] to explore and identify the different ALSA components in the Debian distribution for BBB
The presence of /proc/asound directory indicates that ALSA is present:
The file /proc/asound/cards tells you which sound cards are present in the system. Here is BBB without any external devices. It says there is a native sound device.
The file /proc/asound/devices tells you the features of the cards. The native sound device is an audio playback device.
The file /proc/asound/pcm gives us more detail on the “digital audio playback” (PCM). Here we find that the audio device is provided by the HDMI interface.
The simplest say to identify which cards are installed in the system is to use “aplay -l” [link]. This gives the same info as /proc/asound/cards and /proc/asound/pcm
Further information on the device capabilities can be obtained from the file /proc/asound/card0/pcm0p/sub0/hw_params. It requires that a track is being played. Notice we use “card0” because the card has been identified as “card0”
alsacap
alsacap serves to list the sampling rates, number of channels and sample formats supported by installed sound cards and their ALSA drivers. This helps to find out which parameters do not require resampling (something to be avoided) and to troubleshoot ALSA problems [link]
However, the tool is only available as source so it needs to be compiled. Here is a sample output from here [link]
$ alsacap
*** Scanning for playback devices ***
Card 0, ID `SB', name `HDA ATI SB'
Device 0, ID `VT1818S Analog', name `VT1818S Analog', 1 subdevices (1 available)
2..8 channels, sampling rate 44100..192000 Hz
Sample formats: S16_LE, S32_LE
Subdevice 0, name `subdevice #0'
Device 1, ID `VT1818S Digital', name `VT1818S Digital', 1 subdevices (1 available)
2 channels, sampling rate 44100..192000 Hz
Sample formats: S16_LE, S32_LE
Subdevice 0, name `subdevice #0'
ADDING A USB AUDIO DEVICE
Unlike a PC, a reboot is required for the system to detect the presence of a USB audio device.
After connecting a TI PCM270x-based device (USB 1.1)
After connecting DIYINHK XMOS-based device (USB 2.0)
After connecting AMANERO board (USB2.0)
As can be seen, these cards are all automatically recognized by BBB.
ENABLING I2S OUTPUT
diyaudio’s MIERO has developed a driver to enable I2S output in the BBB [link].
It requires that the HDMI output be disabled (since it shares the same lines with Audio I2S). In my installation, the line to disable HDMI is already there as a comment, so I just had to un-comment it and reboot.
With HDMI disabled (and no other device in the USB port) -no sound cards detected:
Here are the instructions (copied from the site) to download and install the I2S driver for BBB/Debian. You can just copy each line and paste it in the PuTTY windows (paste by clicking the right mouse button.
download and extract driver wget http://bbb.ieero.com/botic_driver_v3.tar.gz tar xvzf botic_driver_v3.tar.gz install driver (assumes official BBB Debian release) cp -av botic_driver/firmware /lib/ cp -av botic_driver/modules.bbbdebian/* /lib/modules/ update module dependencies depmod -a load driver (Needed after every boot) echo BB-BONE-BOTIC1 > /sys/devices/bone_capemgr.*/slots There are 3 configurations for the driver BB-BONE-BOTIC1 - this is for BBB without cape - onboard clock (48fs rates only) BB-BONE-BOTIC2 - onboard clock (48fs rates) - external clock (44k1fs rates) - external clock switch on UART1_TXD (pin configurable via DT) BB-BONE-BOTIC3 - external clock (48fs rates) - external clock (44k1fs rates) - external clock switch on UART1_TXD (pin configurable via DT)
aplay -l shows the following
The I2S pins are the following:
TESTING WITH APLAY
Rather than testing with MPD which might invoke its resampler by default, we will use aplay (alsa player) which does not have a resampler of its own. It is a lightweight player for alsa.
I compiled a collection of tracks from 44KHz to 384KHz
Type=hw: bypassing the mixer
The entry in /etc/asound.conf is as follows:
pcm.!default {
type hw
card 0
}
Using this configuration requires that the source file matches both the bit depth and sample rate supported by the hardware. For example, if using the BOTIC driver (which enables I2S output) which is set as 32bit device, you cannot play 16bit nor 24bit files. The error message indicates that only “S32_LE” (Signed 32 bit Little Endian) is supported:
Type=plug, enabling the ALSA mixer
The entry in /etc/asound.conf is as follows:
pcm.!default {
type plug
slave.pcm {
type hw
card 0
}
}
The result is that “dmix”, the alsa mixer is invoked. With a reputation of being bad, hopefully it does fine with bit-stuffing (e.g., converting 16 bit to 32 bit by appending zeros)
Testing the BOTIC driver we obtain the following results:
Playing a 44.1KHz file. We expect conversion to 48KHz because the native I2S in BBB only supports 48KHz and its family of sample rates. And indeed, this is what we find. The first screen shows playing the 44K file; the second screen shows the contents of /proc/asound/card0/pcm0p/sub0/hw_params showing that it is outputting 32-bit 48KHz. Thus we see dmix in action, doing sample rate convertion
Playing a 192KHz. We expect no sample rate conversion as this is natively supported by the BBB, but dmix will convert from 24 bit to 32 bit. Indeed, this is what we find. The first screen shows playing the 192K file; the second screen shows the contents of /proc/asound/card0/pcm0p/sub0/hw_params showing that it is outputting 32-bit 192KHz. We hope that dmix is just bit-stuffing…
If playing 176KHz, ALSA resamples to 192KHz.
REFERENCES
BEAGLEBONE BLACK for AUDIO
Update (4/1/14)
I purchased my BBB from MakerTronics. I received info that there is a new version, Rev C, with more memory [link] and $10 more.
—
I had ordered a BBB for no other reason that it’s better looking than the Rpi :-). That was before all the discussions at diyaudio and efforts to build an external clock board. But as it turned out, the BBB has the edge for audio application. Here is why:
| Parameter | Rasberry Pi |
BeagleBone Black |
Comments |
| Native I2S support | Yes | Yes | Both platforms can support I2S output, but it needs to be supported in the s/w. |
| 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 |
| 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 | Unknown | Yes | 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] | 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 | 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 | Medium | Good | 🙂 |
In addition, even though the Rasberry Pi has the most community development support, the BBB is a close second, so there is ample resources available. The s/w part is a big part of the solution.
BEAGLEBONE BLACK
CPU: AM335x 1GHz ARM® Cortex-A8
RAM Chip (512M DDR3)
Flash Storage Chip (2GB 2MMC)
Power Management Chip
The TPS65217 [link] is a single chip power management IC specifically designed to support the AM335x series of application processors in portable and 5-V, non-portable applications. It provides a linear battery charger for single-cell Li-ion and Li-Polymer batteries, dual-input power path, three step-down converters, four LDOs
Potential lower-noise mod?:
According to page 2, 30 of datasheet:
For low-noise applications the devices can be forced into fixed frequency PWM using the I2C interface.
…
The TPS65217 step down converters typically operate with 2.25-MHz fixed frequency pulse width modulation (PWM) at moderate to heavy load currents. At light load currents the converter automatically enters Power Save Mode and operates in PFM (Pulse Frequency Modulation).
This is a s/w mod. However I2C access to the chip seems not easy at this moment. According to this article [link]:
The TPS65217C PMIC is very programmable; it has dozens of configuration settings specifically for charging and it has safety timer capability. The PMIC is configured upon startup via I2C. There are three I2C busses on the BBB, and one is dedicated to on-board peripherals. Control of the PMIC is not normally possibly by the user; it requires driver code or possibly there is access by the device tree infrastructure. Checking the .dts file in /boot did not reveal how to control the battery charger functionality. There are two current Google Summer of Code (GSoC) projects that touch on PMIC:
1. IIO, ADC, PMIC, LCD debug/patchwork (summary page, blog page) – Zubair Lutfullah
2. MINIX I2C drivers (summary page, blog page) – Thomas Cort
Hopefully the guys working on the projects (Zubair and Thomas) can offer some advice on how to set the level to 4.2V. Zubair’s project also includes how to use the in-built ADC inside the AM3359 to monitor voltages.
According to the datasheet, “light load current” seems to be at the 1 mA range. Perhaps during operation, the device may never enter the PFM mode and therefore this mod may not be needed at all.
USB Host connector
The current preferred mode for audio is to use a USB audio interface to the DAC because BBB cannot support 44.1KHz sample frequencies with the on-board clock. The interesting part is that the 5V power in the USB host is provided by “SYS_5V”
“SYS_5V” is essentially the 5V DC input to the board. The 5V line goes through a series of solid state switches for power up/down management. Therefore a clean 5V supply to the board will also provide a clean 5V to the USB audio interface. Further filtering is provided by the FB7 ferrite.
I2S Output
BBB audio is generated by the main processor, the AM335x 1GHz ARM® Cortex-A8. The Multichannel Audio Serial Port (McASP) subsystem is responsible for generating the audio using and external audio frequency oscillator. In this case it is a 24.576 MHz oscillator connected to the clock input pin of the processor’s audio subsystem
According to the BBB System Reference Manual, page 75 [link]:
6.10.6 Audio Interface
There is an I2S audio interface between the processor and the TDA19988. Stereo audio can be transported over the HDMI interface to an audio equipped display. In order to create the required clock frequencies, and external 24.576MHz oscillator is used.
…
In order to create the correct clock frequencies, we had to add an external 24.576MHZ oscillator. Unfortunately this had to be input into the processor using the pin previously used for GPIO3_21. In order to keep GPIO3_21 functionality, we provided a way to disable the oscillator if the need was there to use the pin on the expansion header.
Therefore, since a bit-clock has to be generated from this external 24.576MHz clock, only the 48KHz family of sample rates can be supported. Notice that the most common high res sample frequencies are 96KHz and 192KHz and are fully supported by the board.
Notice that since the 24.576MHz clock is fed through an external interface, the audio subsystem is operating in SLAVE MODE. This is according to the datasheet [link]. This master clock is also available external through pin 25 of header P9.
The I2S Pins are as follows on the header P9 (clearly labeled on the board) [link]:
There is a good discussion on I2S audio output here [link]
EXTERNAL CLOCK BOARD
I don’t know about the “unfortunately” part above, but for audio, disabling this clock and having access to the clock line through GPIO3_21 allows the use of an external clock (so this turned out to be fortunate for audio applications).
The solution for bit-perfect audio for all sample rates is to provide the clocks externally through an expansion “cape”. This cape would have two clocks: one to support the 44.1KHz family of frequencies and another to support the 48KHz family of sample frequencies. Two other I/O pins are used to select the appropriate clock frequency. In addition to an external clock board, s/w needs to be developed to enable this function. More discussion here: [link], [link].
This “external clock board” is currently being discussed here
It is important to reiterate that without this not-yet-available clock cape, the BBB would not be able to support the 44.1KHz family of sample rates through its I2S interface. In the meanwhile, while we await the development of the dual clock board, the USB interface would be the preferable method for audio output.
GETTING STARTED
The first thing to do is to check the board and ensure it is working. Follow the Getting Started Guide [link]. Here is what you do:
- To get started all you need is to connect the BBB board to a computer with the included USB cable. This will power the board and provide an interface to the board
- The BBB comes already loaded with an operating system (currently Angstrom) in the on-board eMMC flash memory. Once you power it on, it will boot-up.
- After boot, you will see the BBB board as a storage drive in your computer. From power-on, this booting process takes about 24 seconds.
- Following the link the the “Getting Started Guide” install the device drivers that will enable “network-over-USB” access to your BBB board
- Type http://192.168.7.2 in your browser and you will see the following screen
Terminal Session
You may want to access the BBB with a terminal session. Download “putty” [link] (for Windows) and run it. Enter BBB IP address (192.168.7.2), you will see a log-in prompt. Enter “root” for login and nothing for password.
The official getting started guide is here: [link]
CUBIEBOARD FOR AUDIO?
We’ll explore bit-perfect I2S output in the Cubieboards…
There are two current versions of the boards: Cubieboard2 ($65) and Cubietruck ($95) [link]. Both boards are based on the Allwinner A20 dual core processor.
A20 I2S SUPPORT
According to the A20 datasheet (p.20) [link] the chip supports up to 8 channels of I2S output: DO0 to DO3 represent the 4 stereo channels of I2S data.
The A20 User Manual describes the block diagram for I2S: The clocks for I2S are all based on “Audio_PLL” Master Clock.
Audio_PLL is the audio frequency clock derived from the 24MHz system clock. The PLL generates the 24.576 MHz and the 22.5792 MHz clocks. This means that the A20 is capable of bit-perfect playback for both the 44.1KHz and 48KHz family of sample rates.
The specification also lists the supported sample rates (44.1KHz to 192KHz) and the supported Fs
In Summary, the A20 processor has excellent support for I2S. All sample rates from 44.1Khz to 192Khz are supported. The processor generates the required Master Clock frequencies of 24.576 MHz and 22.5792 MHz through standard PLL processing.
CUBIEBOARD2 I2S PINS
According to the schematics [link] we find that the I2S pins are not connected to the expansion headers. PB5, PB6 and PB7 which are the Master Clock, Bit Clock and LR Clock are not connected.
Therefore, there is no support for I2S in the Cubieboard2
CUBIETRUCK I2S PINS
According to the schematics [link] we find that the I2S pins ARE connected to the expansion header C9. Notice that some jumper/resistors may need to be installed/removed.
In the lower part of the diagram (left side) shows the I2S signals corresponding to PB5-PB8 above. Shown also are the resistors/jumpers that are to be installed or removed in order to connect to the right side. Those connections corresponds to the CN9 header pins 18, 20, 22 and 24.
Notice that the default connection to pin 18, 20, 22 and 24 of header CN9 is to the TVIN signals (TVIN0 to TVIN3). In order to use the I2S signals, the jumpers need to be removed from the TVIN signals and installed in the I2S signals (I2S-MCLK, BT-PCM-CLK, BT-PCM-SYNC and BT-PCM-OUT)
Thus the I2S signals can be made available as follows:
- Pin 18 of CN9: Master Clock
- Pin 20 of CN9: Bit Clock
- Pin 22 of CN9: LRCK
- Pin 24 of CN9: Data Out
According to this post [link]. The modification to the resistors/jumpers are as follows:
remove R175 and set R174
remove R177 and set R176
remove R178 and set R179
remove R180 and set R181(Only need to modify these for stereo I2S)
remove R183 and set R182
remove R185 and set R184
remove R187 and set R186
remove R189 and set R188
R175 to R181 are for the left side of CN9. Those connectors are for multichannel I2S. So for Stereo I2S only modding R182 to R189 are required.
You can see the surface mount resistors that need to be modified in the following photo and diagram. Seem pretty easy to mod.
Another option is just to connect a wire to the appropriated resistor pad and leave the resistors in their original position.
One more observation: Cubieboards are developed by a team of young engineers…
SUMMARY
The A20 processor has excellent support for bit-perfect I2S digital audio. However, only the CubieTruck board allows access to the I2S pins.
REFERENCE
Audio discussion on Cubie Forum: [link]
Low Cost Audiophile Music Servers
DIY Audio is getting a huge boost from two recent developments in the form of RuneAudio and Volumio which run on low cost hardware such as the Rasberry Pi and the BeagleBone Black. This new breed of music “appliances” constitute a step forward for music reproduction because they operate on simpler single-board computers where the OS can be highly optimized for (only) music reproduction and stripped of all other unnecessary tasks.
Note: there are earlier implementation of multimedia software on these platforms -such as XBMC on Rasberry Pi-, but here we have audio-only implementations.
Both teams were working together and created the custom user interface, but due to some “chemistry mismatch” they split a while back. It is good to see however, that there is mutual respect and healthy competition between the teams resulting in better products ultimately benefiting the end user. You can read more here [link] and here [link].
As of this writing, the two projects share a common user interface (soon to diverge into their own versions), but use different UNIX flavor in their OS internals. Both use MPD [link] as the music server application. Currently, Volumio supports I2S output, whereas RuneAudio will have I2S output in the upcoming 0.3 release.
USB INTERFACE TO THE DAC
The more “mature” way to interface the music server to a DAC is through its USB interface. I say “mature” because these interfaces have been available for a while and there are many solutions where in order to support bit-perfect playback, the audio clocks (the 44.1KHz and family; the 48KHz and family of frequencies) are generated by dedicated on-board oscillators.
However, there is still the driver consideration. Theoretically these interfaces should be supported by the OS (which are all Linux derivatives) without installing device specific drivers; but in practice this may not be the case. Here are potential interfaces: [link]
I2S INTERFACE TO THE DAC
The second way to interfacing to the DAC is through I2S which is a very appealing option because it “does away with another component” resulting in an even simpler solution: just the single board computer and the DAC. There is no need to transfer the audio data through the USB interface. The main concern here is whether or not the platform is capable of bit-perfect playback. Lets explore these in more detail.
BeagleBone Black (BBB) I2S output
BBB audio is generated by the main processor, the AM335x 1GHz ARM® Cortex-A8. The Multichannel Audio Serial Port (McASP) subsystem is responsible for generating the audio using and external audio frequency oscillator. In this case it is a 24.576 MHz oscillator connected to the clock input pin of the processor’s audio subsystem (See page 75 of the BBB System Reference Manual [link])
6.10.6 Audio Interface
There is an I2S audio interface between the processor and the TDA19988. Stereo audio can be transported over the HDMI interface to an audio equipped display. In order to create the required clock frequencies, and external 24.576MHz oscillator is used.
…
In order to create the correct clock frequencies, we had to add an external 24.576MHZ oscillator. Unfortunately this had to be input into the processor using the pin previously used for GPIO3_21. In order to keep GPIO3_21 functionality, we provided a way to disable the oscillator if the need was there to use the pin on the expansion header.
Because there is only a 24.576MHz clock, only the 48KHz family of sample frequencies can be supported. Seems audio (or bit-perfect audio – or perhaps “legacy 44.1K audio”) was not a big concern for the designers of the BBB. HDMI, which defaults to 48KHz audio was the primary concern.
Notice that If playing high res music, it can support 96K, 192K and also 384K (24576000/64=384000Hz)
Fortunately, GPIO3_21 is an expansion pin accessible from the outside and the on-board oscillator can be disabled by s/w.
The solution for bit-perfect audio is to provide the clocks externally through an expansion “cape”, using one or two other I/O pins to select the appropriate clock frequency (and the s/w driver that would enable the use of the external clocks) More discussion here: [link].
Rasberry Pi I2S output
There are some hints that the RPi is capable of of 44.1K output in the I2S interface. I can’t find a definite reference of bit-perfect playback. If I had a RPi I would just hook it to one of my ESS DACs and observe the actual sample frequency. Several I2S DACs have already been developed that seamlessly plug into the RPi expansion headers [link].
But is the RP1 I2S bit perfect?
In the RPi, the audio is generated by the Broadcom BCM2835 [link] peripheral SoC chip. The audio frequencies are generated through an 0n-board 19.2 MHz oscillator. (Photo from here [link]).
If applying integer division to the clock, exactly 48KHz (and its family) can be supported. However, the highest sample rate that can be supported is
19200000/64=300KHz or effectively 192KHz.
According to the Datasheet, the Audio system is driven by a master clock “PCM_MCLK”. According to this thread [link], seems this master clock is generated internally by the clock generators. According to the Datasheet, the clock generators can use “fractional clock dividers”. The Datasheet indicates:
6.3 General Purpose GPIO Clocks
The General Purpose clocks can be output to GPIO pins. They run from the peripherals clock sources and use clock generators with noise-shaping MASH dividers. These allow the GPIO clocks to be used to drive audio devices.
The fractional divider operates by periodically dropping source clock pulses, therefore the output frequency will periodically switch between:
frequency source /DIVI & frequency source /DIVI+1
Jitter is therefore reduced by increasing the source clock frequency. In applications where jitter is a concern, the fastest available clock source should be used. The General Purpose clocks have MASH noise-shaping dividers which push this fractional divider jitter out of the audio band.
Thus, fractional dividers can be used to generate the 44.1K frequencies (or rather 44.1Kx64 for the bitclock) by using the above built-in method. Audiopurists would cringe at the “periodically dropping source clock pulses” part.
No master clock output in RPi
According to the Broadcom BCM2835 datasheet (pp. 119-120),
The PCM audio interface has 4 interface signals:
PCM_CLK – bit clock.
PCM_FS – frame sync signal.
PCM_DIN – serial data input.
PCM_DOUT – serial data output.…
In clock master mode (CLKM=0), the PCM_CLK is an output and is driven from the PCM_MCLK clock input.
In clock slave mode (CLKM=1), the PCM_CLK is an input, supplied by some external clock source.
This lack of master clock output can also be seen in the P5 header of the RP1 [link]:
And Also as indicated from the developers of RP1 DACs [link]
What about the SCLK (MCLK) signal on DAC chip?
The Raspberry Pi (RPi) does not provide such a signal, it outputs just the other I2S signals: LRCK, DATA and BCK, but not a system clock.
…
The PCM1794A works well if the SCLK (MCLK) signal is connected with the BCK signal which is done on the RPi-DAC board via a jumper (SCLK is BCK).
The PCM_MCLK is the master clock and it seems internally generated. There is no other reference to PCM_MCLK in the datasheet. The bit-clock (PCM_CLK) is the reference clock used for I2S.
RPi Jitter numbers?
According to this post [link], there is a single phase jitter data point of -54 dBc/Hz at 100 Hz (for a carrier frequency of 1.411 MHz, which is the sample rate for 44.1KHz/16bit). What does this mean?
Typically one would see phase jitter plots for clocks and typically at the source frequency (e.g. 24.576Mhz, etc). Here is a phase jitter value of the bit-clock. In the case of RPi, this clock is derived from the 19.2MHz and scaled by “fractional clock divider”
I was able to find a phase jitter plot from Audiophileo [link]. There the phase noise of the device is compared against the phase noise of the device with a “jitter simulator” turned on. The carrier frequency is 2.822 MHz, which is the frequency of 44.1KHz/32bit. This frequency corresponds to the bit-clock, so hopefully this is a fair comparison.
The plot below is the plot from Audiophile0 with the phase jitter value of -54 dBc/Hz at 100 Hz superimposed. I followed the same slope as the other curves and extrapolated to 1 Hz. Then I used a jitter calculator to find the RMS jitter [link]. The result is shown below. The jitter value for the RPi is the green dotted line. The pink line represents the added jitter to the Audiophileo native jitter which is shown in the blue line.
WHICH PLATFORM?
The two most popular (and lowest priced) boards are the Rasberry Pi (RPi) and the BeagleBone Black (BBB). Here is a nice comparison of the two boards [link].
Here is my comparison for audio (please comment if you see any inaccuracies).
| Parameter | Rasberry Pi |
BeagleBone Black |
Comments |
| Native support for 44.1K and family | Yes, through “fractional clock dividers” | No | It remains to be seen how much jitter is introduced by the “fractional clock division” of the RPi |
| Native Support up to 384KHz | No. On-board clock is 19.2MHz | Yes. On-board clock is 25.576MHz | RPi can support up to 192K material |
| Support for USB DAC | Yes (LAN9512 chip [link]) | Yes (Built-in in the main processor) | USB in the RPi goes through a buil-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 and LAN by a separate chip |
| External Clock capability | ?; likely not | Yes | The master clock in BBB can be provided externally by disabling the on-board audio-freq clock. The Master clock in the RPi seems internally generated |
| Built-in rechargeable battery operation | No | Yes [link] | Rechargeable Batt operation in BBB would disable the 5V supply to the USB. Thus for USB operation, where the USB adapter takes the power from USB, it must be powered with 5V DC |
SUMMARY
I’d say that the current best option for audio is through a USB-I2S device until the clock issues are better understood. The current best option for a computing board is the BBB primarily because it can support (or more likely to support) and external clock board. If you already have RPi/I2S-DAC and are happy with it, that’s what really matter…
H i F i D U I N O 
Latest Comments