2014/07/01 9 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 5 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 9 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
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, 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)


2014/03/10 20 comments

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


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]


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.


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 in your browser and you will see the following screen

BBB out of the box (shows up as a storage device)


BBB after installing network-over-USB drivers (address:


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 (, you will see a log-in prompt. Enter “root” for login and nothing for password.




The official getting started guide is here: [link]


Get every new post delivered to your Inbox.

Join 201 other followers