R2R For The REST of US

2014/10/12 9 comments


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.


The DAC module is not yet available for sale. The target price is US$240 with 0.02% resistors.


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


(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 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 implementers.



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

R2R Module reclocker

  • Clock is Si514 is the lower grade of programmable clocks from Silicon Labs (.8 psec RMS jitter) [link]
  • 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

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 a DAC chip.

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.


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


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”

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.



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.



2014/07/01 14 comments

I have come to the realization that audio diy never ends. There is never the “final” project. There is always tweaking, a new mod,  new stuff. Thus I decided to use a cardboard box as an enclosure. Much easier to work with, simple tools would do.

Many would consider a proper enclosure a must for a diy project, but for me this is good enough. Here is a nice looking Lenovo tablet box.



Three separate transformers were used:

  • DAC supply transformer: salvaged from an VCR from the time that linear supplies were still being used. These transformers are very nice, having at least 2 hefty 9V secondaries.  The secondaries feed a TPA dual PS which is used as a pre-regulators for the DAC supplies.  The two capacitors hanging off the transformer provides DC to an LED (to indicate power 0n/off)
  • Analog supply transformer:  15×2 toroidal transformer. (Got it from Twisted Pear Audio)
  • Controller transformer: 6V DC salvaged from a wall-type supply, upgraded the smoothing capacitors



Water bottle caps are perfect for the feet.



Used a quad-supply board. This board is designed to provide 4 x 3.3V/5V regulated output. Two supplies receives pre-regulated DC, two supplies receive AC (thus the larger filter capacitors).


Two of the regulators were modified to provide 14.2 V (1.4V+6.4V+6.4V) for the opamp by shorting pins 4 and 5 to GND. They are also configured to provide +/- 14.2V by tying the +output of one of the regulators to GND (I followed what diyinhk did for their dual +/- supply [link])




Standard build. Only “upgrade” are the electrolytic capacitors. On the backside, the jumpers are to connect the I2C lines to the separate I2C header because I forgot to short the lines on the front side before I soldered the connector (which blocked the jumpers). Later I will upgrade the opamp.



There is a separate SPDIF input connection that feeds the GPIO2 pin in the DAC. Selecting this GPIO pin for SPDIF input has been enabled in the code.

GPIO1 is configured in the board to be in input selection pin for manual selection of I2S/SPDIF. My code does not enable this mode because the selection can be done directly through the user interface. This is here for manual selection with a switch and requires that the chip be programmed in such a way. I believe the diyinhk XMOS interface would program the chip to allow manual selection of SPDIF input.


The board comes with an NDK 80 MHz oscillator [link]. Other implementations may use a 100MHz clock. The software support both 80 MHz and 100 MHz clocks.

In addition, a separate supply can be used to power the clock by cutting the power trace and connecting the supply to the through-hole vias.



The external 5V powers a single regulator for the analog 3.3V AVCCR and AVCCL. . The second regulator provides 3.3V to in chip internal oscillator (I think in order to support an external quartz crystal instead of an oscillator). The regulators are marked “LLVB” and are TI LP5907 Ultra Low Noise regulators for analog applications [link]. They rank near the top among ultra low noise regulators [link].

The external 3.3V is used directly without further regulation to power the digital side of the chip and also the local oscillator.


Power to the oscillator is further filtered by a ferrite bead



Positive and negative supply voltage are taken directly to power the opmap.



The board has connection for the differential outputs straight out of the DAC chip and also single ended output through the opamp. I am using the single ended output wired to a mini-plug for connection to a headphone amplifier. The opamp provided is a NE5532 dual operational amplifier [link]




Nice, solid ground-plane







ES9018K2M Code Fully Tested

2014/06/30 Leave a comment

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]






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:

/***************** End Code Customization Section *******************/   

This code should also work with syllable’s DIY DAC [link] which is also described in this builders thread [link]


S/W Control for ES9018K2M

2014/06/13 5 comments

Here is the initial public release of the s/w control code for the NEW ES9018K2M DAC [link]. This project was completed at this (early) time due to the insistence of “syllable” at diyaudio who is running a group buy for his DAC board [link].

Download the code here [link]


The code is based on the ES9018 code and supports revision V of the chip (“E” marking in the third row of the text). It is also based on the 5/15/14 version of the official data sheet (available through authorized distributors and under NDA)



(As compared to what is available in the older ES9018 DAC)

  • Support for a minimum phase FIR filter
  • Support for separate DPLL settings for I2S and DSD (16 settings for each)
  • Support for FIR filter (oversampling) bypass AND IIR filter bypass
  • Exposed De-emphasis filters
  • Enabled balance control in 0.5 db increment


I will be using the diyinhk implementation of the ES9018K2M (it is already populated and ready to use. I realize that I am getting to lazy to start with bare boards and some the surface mount chips I cannot properly solder).

The power supply is an older quad-supply board also from diyinhk which I’ve hacked to also provide +/14.x v. in order to power the opamp


Using my latest favorite Arduino clone (only $10) [link]. The two small boards hanging on the pins are a LCD backlight control and a 5V to 3.3V level converter. As I realize that this audio diy hobby is never ending, I figure doing things the easy way trumps doing things the neat way (like for example using an Arduino shield) so I soldered the wires directly on pins that I plug into the board.



2014/04/01 6 comments


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

DSC04403 DSC04404

The Core board

The A20 core board  [link] is designed as a “computer on a module” and consists of

  •  Allwinner Technology A20 SoC
  • 1 GB DDR3 RAM
  • 4 GB NAND Flash
  • Power Management Unit (AXP209)

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




Since this site is dedicated to audio, we will focus a bit on the audio capabilities of iBox


According to the datasheet, The A20 has the following built-in audio features:

Analog Output

  1. DAC
    • 16bit, 24-bit data
    • 44.1KHz, 48KHz, 96KHz and 192KHz sample rate
    • 100 db SNR
  2. Analog/Digital volume control (62 steps)
  3. 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:




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


  • 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.



I shall get familiar with the software environment and report shortly in the next post…


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.


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.


  • 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]




2014/03/27 8 comments

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.


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.


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:

Name Description
type The name of the plugin.
name The name of the audio output. It is visible to the client. Some plugins also use it internally, e.g. as a name registered in the PULSE server.
format Always open the audio output with the specified audio format (samplerate:bits:channels), regardless of the format of the input file. This is optional for most plugins. Any of the three attributes may be an asterisk to specify that this attribute should not be enforced, example: 48000:16:*. *:*:* is equal to not having a format specification.The following values are valid for bits: 8 (signed 8 bit integer samples), 16, 24 (signed 24 bit integer samples padded to 32 bit), 32 (signed 32 bit integer samples), f (32 bit floating point, -1.0 to 1.0). Note: /etc/mpd.conf states: “This setting will change all decoded audio to be converted to the specified format before being passed to the audio outputs.”  Therefore do not use this parameter.
enabled yes|no Specifies whether this audio output is enabled when MPD is started. By default, all audio outputs are enabled.
tags yes|no If set to “no”, then MPD will not send tags to this output. This is only useful for output plugins that can receive tags, for example the httpd output plugin.
always_on yes|no If set to “yes”, then MPD attempts to keep this audio output always open. This may be useful for streaming servers, when you don’t want to disconnect all listeners even when playback is accidentally stopped.
mixer_type hardware|software|none Specifies which mixer should be used for this audio output: the hardware mixer (available for ALSA, OSS and PulseAudio), the software mixer or no mixer (“none”). By default, the hardware mixer is used for devices which support it, and none for the others. Note: etc/mpd.conf states: This example will not allow MPD to touch the mixer at all and will disable all volume controls: mixer_type “disabled”
replay_gain_handler software|mixer|none Specifies how replay gain is applied. The default is “software”, which uses an internal software volume control. “mixer” uses the configured (hardware) mixer control. “none” disables replay gain on this audio output.

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:

  1. Specify ALSA as output plugin
  2. Specify that no mixer should be used in audio output plugin
  3. Specify that no volume adjustment be applied
  4. Further disable “dmix” the ALSA mixer (#2 may do the same thing. But you never know…)
  5. Further disable resampling in the output (dmix?)
  6. 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.


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”


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


Use the following entry in /etc/asound.conf

pcm.!default {
	type plug
        slave.pcm {
              type hw 
	      card 0



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 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'



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.


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)
- onboard clock (48fs rates)
- external clock (44k1fs rates)
- external clock switch on UART1_TXD (pin configurable via DT)
- 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:



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.


  • Automating the mpd configuration process for bit-perfect audio: [link]
  • Must read: bit-perfect audio in Linux: [link]
  • An example configuration for MPD and ALSA [link]


2014/03/21 2 comments


I set up a network share by inserting a USB memory stick to the Airport Extreme WiFi router.

  • Address of Airport Extreme:
  • Name of memory stick: MUSIC (later I changed it to MUSICUSB), fat32 formatted
  • password for share: XXXX

1- install the “cifs.utils” package with “apt-get install”


2- mount the share with the following command


  • mount -t cifs does the same thing (it invokes mount.cifs)
  • “//” is the share on the Airport Extreme “MUSIC” is the name of the USB Stick inserted in the Apple Airport Extreme router
  • “/media/nas” is the mount point. I created the “nas” directory under /media
  • “-o” is the options flag
  • “username=any” means no user name is needed (as it is set up in the AE)
  • “password=XXXX” is the password used to secure the share (as setup in the AE)
  • “sec=ntlm” is the password security mode. Without it you’ll get an “error (22): invalid argument”
  • More info here [link]


Here we will use /etc/fstab and mount the share at boot time. The network share is seldom removed, so mounting it during boot is the best option. I use the following line:


  • Here I had changed the name of the USB Memory device to “MUSICUSB”
  • This assumes that your network share is always the same name
  • More info here: [link]


2014/03/19 5 comments


Once the operating system is flashed to the internal eMMC, the uSD card can be used as storage and it is a convenient means to store music tracks.

The command “fdisk -l” will list all the storage devices seen by the operating system:

Here is without any devices in the uSD slot. Listed is the internal eMMC storage device (listing only relevant parts):


After inserting a 32MB uSD card we see this additional device:


After inserting a 2 GB uSD card we see this device instead:


We realize that the any card inserted in the uSD slot is characterized by “/dev/mmcblk1p1″. “mmc” stands for “multimedia card” -both SD cards and eMMC devices conform to the “multimedia card” specification. “blk1″ I think represents “block device 1″ and “p1″ is “partition 1″

However, if the uSD card is already inserted during, we see the following:


The device is assigned /dev/mmcblk0p1. It appears the the order the device numbers are assigned at boot time is uSD card first, then internal eMMC.

Mounting the uSD card

In order to access the contents on the uSD card, the device must be first mounted. First create a “mount point” (a folder). Here I use the directory /media which is already present. Under /media create a directory to mount the uSD card.  I created /media/card, /media/usb and /media/nas to represent the 3 different places where music tracks can be stored.

Use the command “mount”


The “-v” flag in “mount” is optional. Means “verbose”. Notice that after mounting the uSD card, I can see the “smallmusic” directory and 1 mp3 track.

Keep in mind that if the uSD card is already inserted at boot time, it is assigned “mmcblk0p1″ instead of “mmcblk1p1″


If digital audio is transmitted through the I2S interface, then the USB host can also be used for a USB memory device.

The same procedure can be used to mount a usb memory stick:

  1. Insert a USB storage to the USB host connector
  2. Type “fdisk -l” to identify the device. Notice that it is /dev/sda1
  3. Type mount /dev/sda1 /”mount point” in my case, mount /dev/sda1 /media/usb

Inserting a USB storage device will show up as:


Since there is only one usb host port, a USB memory device will always appear as /dev/sda1 whether it is present during boot or not.


It becomes cumbersome to have to access the board through the command line in order to mount a storage device. For a music device, the ideal is to have these storage devices mounted automatically.

I tried different ways to auto-mount the devices when they are inserted:

  • Autofs: looks like the most promising but did not work in my installation while following this excellent guide [link]
  • usbmount: works well with uSD cards and USB storage at any time after boot, but when deleting the X11 package, it wound fail to mount uSD cards. usbmount was last updated in 2007 and is currently unmaintained.
  • Add mount instructions in /etc/fstab which is invoked only during boot time.

For now the “best” option in my environment seems using /etc/fstab and ensuring the storage devices are present during boot. This seems a reasonable configuration for an audio player: Insert the storage devices and turn-on the device. Even if switching to another storage device requiring a reboot, the booting process is very short.

usbmount has better functionality because it works after boot. I didn’t like the fact that it stopped working for SD cards after I removed the X11 package (which I do not need). I’ll wait for more help on autofs and then I think I’ll switch to autofs.

For USB I added the following line to the /etc/fstab file.


Note the following:

  • Add the “nofail” option. Without it the board will not be able to boot if no USB memory is present in the USB port.
  • Ensure that the USB memory has a single partition since we are assuming it is always /dev/sda1. A newly formatted USB memory device will have a single partition

For the uSD Card and assuming that the card is inserted prior to boot, I added the following line:


Insert a uSD card and a USB memory device, boot the board and they will be mounted under /media/card and /media/usb (or whatever directory you had specified in /etc/fstab.


2014/03/18 5 comments

In order to do some useful stuff and have the ability to download applications, the BBB board must have direct access to the internet.

Decided to set up the Ethernet interface with a static IP address. Having a static address allows you to know how to access BBB all the tiem without the need to check  the router for the assigned IP address. Choose a large address in order to avoid address conflict with existing assigned IP addresses. Choose and address that is easy to remember. You could also reserve this address in the router.

The way this is done in unix is to edit a configuration file. Since we don’t have the luxury of a GUI, everything is done through a terminal window on the command line. Learn to use “vi” or equivalent. vi is universally available in any UNIX/LINUX distribution. For the beginner, using vi is a bit of a pain, but it is easy to master the basics very quickly.


According to the Debian Wiki [link], this is the format:


Modify the entry in /etc/network/interfaces and follow the above format. In the command line type “vi /etc/network/interfaces”

This is how I modified the configuration. I use an Apple Extreme router which defaults to assigning a 10.0.1.x network


And indeed, it is accessible though “” after connecting it to a wired network (see the address in upper left corner of the tty windows above). It remains also accessible though USB with an IP address of as shown below:


Edit the /etc/resolv.conf file. Change nameserver to be the new gateway:


Originally It was set to the factory nameserver  ( Without this fix, I was not able to resolve domain names through my WiFi connection.


Wanted to try a USB WIFI adapter on the Beaglebone Black board running the official Debian release. I got a hold of the TP-LINK TL-WN725N v2 adapter, a very popular device and retailing for under $10.


As it turned out, no drivers are available for the device from the manufacturer and the device might or might not be supported by the operating system distributed with the BBB board.

According to the Debian Wiki [link]

Currently there are only a few modern WiFi chipsets readily available that work with free software systems. For USB wifi devices this list includes the Realtek RTL8187B chipset (802.11G) and the Atheros AR9170 chipset (802.11N). For Mini PCIe all cards with an Atheros chipset are supported.

WiFi has always been a problem for free software users. USB WiFi cards are becoming less free. With the older 802.11G standard many USB WiFi cards had free drivers and did not require non-free firmware. With 802.11N there is only one chipset on the market from Atheros which is completely free.

This means that there are no assurances that the WiFi device would be supported by particular device and operating combo. This also means that as the technology evolves, it would become more and more difficult to find driver support for WiFi devices.

This particular WiFi device, “v2″ uses the Realtek RTL8188EUS [link] chipset (whereas the v1 uses the RTL8188CUS chipset [link]). It is important to know the exact model number and even the version number because different versions of the device might use different chipset and therefore requiring different drivers.

Fortunately, a driver is available in source (from the chipset manufacturer?) and users have been compiling the source for their particular environment.  Here is an example for  RPi Raspbian  [link].

Unfortunately, I have not come across an installation or this driver for the official Debian on BBB and this (compiling the source) is  beyond my skill set and have no real desire to learn it. Additionally, even if you can master these skills every time the operating system is updated, there is a chance that the driver may stop working requiring another round of s/w tweaking.  This sounds like a real pain even for us diyers…

The right thing to do is to purchase a device that has ample support from the user community, the manufacturer or the retailer. Here is an example of well supported USB WiFi devices: [link], [link]. Check also the BeagleBone Black H/W info page for supported WiFi devices [link]. Or one can switch to a Rasberry Pi board :-) [link] which seems to have the widest support.


Eventually, there might be a readily available driver for this WiFi device. However, support for wired network has always been included in all Linux OS releases and is trouble-free and rock solid. No need to hassle with wireless dongles with proprietary drivers that might potentially break with newer releases of the operating system.


The TP-Link TL-WR702N Wireless Router [link] is an excellent option to add wireless connectivity to the BBB (or any other device). This multi-mode WIFI device can be set to “client mode” an provide a wired connection to the BBB while connecting to the wireless router. The exact same configuration is used as with wired network.


Additionally, this device is externally powered so that low noise power supplies (the favorite tweak for audio diyers :-)) can be used.

Powering separately has the advantage of having the NANO continually maintain connection with the main router even while the BBB is being power cycled. Optionally, the NANO is a low power consumption device so that it can be powered through the BBB USB port.


Found these photos here [here]




2014/03/17 6 comments

One of the challenges with these low cost boards running open software is the understanding and installation of the operating system and related audio applications (such as MPD). Although RuneAudio and Volumio are solutions aimed at simplifying the installation process and are specifically geared toward audio, It is still beneficial to understand the s/w installation process “from scratch”.

As I only have a BBB on hand (I have (Rev B) [link]), my experiences are limited to this particular board.


Every BBB comes loaded with the Angstrom operating system from the factory. After installing the network-over-USB drivers on the PC and powering the board with the included USB cable, you can access the board either through a browser or through a terminal application. The board is “fully operational” but it can’t just plat a music track. Configuration of the operating system is required. In addition a more functional music player is also required.

There are many ways of installing and setting up the s/w. And there are all pretty similar. Here are a two notable guides for installing the operating system and the music player application MPD.

  • HIFIWigman: [link]
  • Computer Audiophile: [link]

But every situation and environment is a bit different and thus I shall also share my experiences :-)


The first thing to determine is which OS? We know BBB comes with Angstrom but there are many other versions available. It is a good idea to limit the choices to the “officially supported” choices to minimize potential incompatibilities problems. The current “official” images can be found here: [link].

As of today, there are only two “official releases” of the operating system fully customized for the BBB board: Angstrom and Debian. From reading the forums, Debian provides more support for audio/multimedia applications than Angstrom. At least it seems Debian is easier to configure. There are also plans to have Debian pre-installed on the boards [link]

As of March 5, 2014, BeagleBoard.org is providing customized Debian images on the Latest Images Page and making plans to include those images on production BeagleBone Black boards on the on-board eMMC.

My project was so slow to develop as I had to research every little change I needed for angstrom and then node was too beta to use. I found debian7 on elinux and gave it shot (running from SD). and I gotta say that this has revived my interest in the BBB and now able to spend time on my project and not tuning the OS.

I love that its light weight (no GUI) and fits onto plentiful 2gb cards, the install is vanilla which allows me to install what I need easily with out services clashing. Once I found out about optargs in uenv.txt I was flying. With killer documentation, setup scripts and adafruits python mod installed out of the box – this will just the best!

SD or eMMC?

BBB allows booting either from the internal eMMC (the on-board NAND storage) or from the MicroSD card. The default mode is to boot from the eMMC storage. Pressing the boot-button during power-on allows booting from the MicroSD card. (See the “Booting” section below for more details).

The installation images are different for SD-boot and eMMC-boot. The images that are intended to be installed in the eMMC are called “eMMC-flasher” images. Included is a script that would copy/install the operating system onto the eMMC storage right after booting. Read more about this format here [link].

Booting from the internal eMMC, has the additional advantage that the SD card can then be used to store music tracks.



  1. Download the eMMC flasher version: BBB-eMMC-flasher-debian-7.4-2014-03-04-2gb.img [link]. The official Debian image was made available just a few days ago.
  2. Extract the downloaded .XZ file (BBB-eMMC-flasher-debian-7.4-2014-03-04-2gb.img.xz) with 7-Zip
  3. Copy the file to a MicroSD with Win32 DiskImager  (This takes about 3 minutes with a Class 10 card). Copying to a regular SD card can take 2-3X the time.
  4. Insert the MicroSD card and boot by pressing the boot button while applying power. The copy/installation of the OS will commence. The 4 USR LEDs will start flashing

The following image shows the Win32Disk Imager application copying .img file to the MicroSD Card (step 3 above)


The 4 USR LEDs flashing while the OS is installed in the eMMC storage (step 4 above)


When the installation is complete, the 4 USR LEDs will be lit solid. This installation process took about 13.5 minutes with a Class 10 MicroSD card.



After removing the uSD card, BBB will boot off the eMMC when you power cycle the board.

Earlier I thought that with the OS installed in the eMMC storage, every time you power the board, it will boot from the eMMC regardless of whether you have a uSD card in the card slot or not. This is not the case. BBB will boot off the eMMC only if the inserted uSD card is NOT a bootable card. Both the regular image and the eMMC flasher image are bootable images.

If you leave the uSD card (with the eMMC flasher image) inserted and power on the board, the board will boot off the uSD and will start flashing the eMMC (again). Then you will have to wait until the end of the flashing process. Stopping the flashing process in the middle will obviously corrupt the installation.

The requirement to press the boot button when booting from the uSD card (as indicated in the documentation) may only be required when you first power the board as shipped from the factory.


Check the installation by removing the MicroSD card (so it will boot from the eMMC) and connecting the board to a computer with the provided USB cable. The Debian Installation behaves the same as the original Angstrom installation: Upon boot, the board will show up as a storage device:


This is a very good way to check if the installation was successful. The board must quickly show up as storage when connected to a computer through the USB cable. As it turned out in my case, the majority of the installations are successful but not 100%.

The static IP address remains the same: It is a static address specified in /etc/networks/interfaces


This address is only accessible by the computer to which BBB is connected through the USB cable (and the USB-Network drivers are installed). It is not visible anywhere else because it is configured to connect through “usb 0″ as shown above.

Doing a free space inventory on the file system (typing “df” in the command line) we find that the s/w occupies 79% of the available space. The s/w takes up 1.27 GB



There is a slimmer version of Debian for BBB here [link].

  • The slim version is dated 02/16/14 and kernel version v3.8.13-bone40.
  • The official image found here [link] is dated 03/04/14 and kernel version 3.8.13-bone41

(Type “uname -r” to get the kernel version).

After flashing this version in the eMMC, we find the following:


Notice that the s/w occupies 24% in comparison. The s/w occupies 389 KB. I am not sure what is the difference between this version and the “official” version (aside from having more features). However,  it is probably better to use the later versions as these releases are still beta releases and bugs are continuously being fixed. Also, I couldn’t get the network (ethernet) to work in this version.


According to this discussion [link] the eMMC is almost full due to everyone’s out-of-the-box requirements. Things that can be deleted are:

opencv/python/chromium (computer vision s/w) (63MB)

apt-get remove libopencv-* --purge ; apt-get autoremove
rm -rf /usr/lib/chromium/
rm -f /usr/bin/chromium

lxde/xorg package (x11 graphical UI) (222MB) -Note: removing this broke “usbmount” which I was using to automount uSD cards…

apt-get remove -y x11-common ; apt-get autoremove

documentation (59MB)

rm /usr/share/doc -r

Further packages can be removed according to this guide [link]



After removing the above listed packages:



Experiment by removing other packages. To list the installed packages in order of size, use the following command [link]:

dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n

Compared the package list of the official debian (bone41) vs the slim version (bone40) (both as installed in the eMMC).

Listed here are the largest-size packages. -I think these are candidates for removal.


Removed the above packages with the following commands:

apt-get remove python2,7-dev --purge ; apt-get autoremove
apt-get remove vim-runtime --purge ; apt-get autoremove
apt-get remove lib11-mesa-dri --purge ; apt-get autoremove
apt-get remove libgtk2.0-common --purge ; apt-get autoremove 
apt-get remove libgtk-3-common --purge ; apt-get autoremove

These are the savings after each removal. In total, Free space in the eMMC was increased by 567MB.



Notice that after removing libopencv* free space got reduced. Apparently the first time you use apt-get, some files are created (e.g. to hold the package list, etc). In another occasion when installing a package under 1M, free space was reduced from the factory 344MB to 274MB, a net loss of 60MB. Removing libopencv* right after resulted in a net gain of 26 MB.

Note also that since I don’t know much about Linux/Unix, I am not 100% sure these would not cause problems, but I checked the functionality of those packages and they seem to be safe for removal. So do at your own risk :-)

On a side note, configuring Linux/Unix as a beginner can kill a lot of time without accomplish much. In addition, although there is a lot of information in the internet, it is all over the place and covering lots and lots of different configurations. A desktop environment behaves different from an embedded environment. It is best to look for information that closely matches your environment (for example posts about Rasberry Pi will resemble the BBB environment, but posts about Debian running on a laptop may not apply). Further, there are different ways and applications to accomplish the same thing. Some work (for me) and some don’t work.

I guess the wise thing is do is to take advantage of the work from the people at RuneAudio and Volumio. RuneAudio even says that the OS is built to include only the essential components which beats my approach of slimming down an installation.

In the meantime, it is still good to have some understanding on the internal behavior of the operating system. Enjoy hacking :-)

Update (3/21/14)

I’ve used the following sequence to remove packages and recorded how much free space is left. Using autoremove removes other packages that are part of the main installation, packages that are subsequently removed may result in very little space savings because the dependent packages may have already been removed with autoremove.

In addition:

  • Removed the packages in the installation uSD so that every time I flash the image to the eMMC, the removed packages are not copied over.
  • Modified /etc/network/interfaces and /etc/resolv.conf in the uSD and this is copied over during the flashing
  • Installed cifs-utils in order to support mounting of share drive
  • Modified /etc/fstab but a new one is generated during the flashing, so it is replaced by a new one. Editing the /etc/fstab is necessary after every flashing to the eMMC or create a newfile with the new fstab entries and append to fstab file with the command: cat etc/newfile>>/etc/fstab


Starting point -252MB Free

Remove X11 package (GUI)

apt-get remove -y x11-common ; apt-get autoremove    -473MB Free

Remove opencv (computer vision s/w)

apt-get remove libopencv-* --purge ; apt-get autoremove   -501MB Free
rm -rf /usr/lib/chromium/ -596MB Free
rm -f /usr/bin/chromium/ -596MB Free

Remove documentation

rm /usr/share/doc -r -655MB Free

Remove Desktop environment GNOME and GTK

apt-get remove libgtk-3-common --purge ; apt-get autoremove   -751MB Free
apt-get remove libgtk2.0-common --purge ; apt-get autoremove   -772MB Free
rm -r /usr/share/icons   -818 MB Free
apt-get remove gnome-* --purge ; apt-get autoremove   -818MB Free
apt-get remove desktop-base --purge ; apt-get autoremove   -818MB Free

Remove vim (since we are using vi)

apt-get remove vim-runtime --purge ; apt-get autoremove   -845MB Free

Remove compilers

apt-get remove cpp-4.6 --purge ; apt-get autoremove   -884MB Free
(This also removes g++, gcc and gcc-4.6 and others...)
(python can also be removed since this assumes no s/w development in the BBB)

Get every new post delivered to your Inbox.

Join 206 other followers