iBOX

2014/04/01 2 comments

DSC04405

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)

DSC04399

Here is compared to the size of a uSD card

 

DSC04396

Front side: uSD card reader, status LED and IR receiver

DSC04400

Side: Multi-function expansion connector

DSC04402

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.

DSC04386

The Power Management Unit, AXP209

DSC04388

24MHz oscillator

DSC04389

Detail Connection to baseboard

DSC04392

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.

DSC04375

DSC04385

USB Hub: GL850G Hub

DSC04380

Ethernet Interface: Realtek RTL8201CP

DSC04381

The board has a 3 Amp switching regulator, the MP2307 set at 5V. The input range of the regulators is  4.75V to 23V.

DSC04387

uSD Card reader, IR receiver and LED indicator

DSC04376

Multi function expansion connector

DSC04377

USB and HDMI connectors

DSC04378

SPDIF Toslink optical connector, Ethernet and power connector. The bundle supply is rated a 9V, 2 Amp

DSC04379

 

 

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

iboxEx

In fact there will be an expansion board [link] available with SATA connectors plus other connectors

IboxSata-001

iBoxCard-001

AUDIO

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

ANALOG AUDIO

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

Analog Output

  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:

A20AnalogOut

DIGITAL AUDIO

Spdif

The iBox has a built-in SPDIF/Toslink connector. According to these discussions [link], the SPDIF output supports:

  • 16bit data
  • Up to 192KHz sample rate

I2S

  • Resolution: 16bit, 20bit and 24bit
  • Sample rates: 8KHz to 192 KHz
  • Format: I2S, Left Justified, Right Justified
  • Frame (BLCK): 16bit, 20bit, 24bit and 32bit

I’ve previously described the I2S capabilities of the A20 processor here [link]. The A20 datasheet (p.20) [link] specifies that the chip supports up to 8 channels of I2S output (DO0 to DO3 represent the 4 stereo channels of I2S data).

A20I2S

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):

IteadCorePins

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.

DSC04382

SOFTWARE

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

ALLWINNER TECHNOLOGY, THE COMPANY

The A20 SoC was announced about a year ago. I have to admit, I had never heard of this company. A bit of digging uncovered that this company is fast becoming a dominant player in the SoC market:

You may never have heard of Allwinner but they are huge and as of CES now have an 8-core tablet part on the market. With the release of the A80 SoC and the OptimusBoard that SemiAccurate used, the company is well positioned for the mainstream tablet market in 2014.

Allwinner rarely makes the headlines because they don’t make bleeding edge products that go in to high-end phones and tablets, instead they make mainstream SoCs that go in to high volume tablets. This mid-range market has decent margins, huge volumes, and since they don’t target phones directly there are no radio hassles and regulation to deal with. How big is Allwinner? Huge. Continue reading: [link]

The most interesting part of this company is their announcement to join Linaro’s newly formed Digital Home market segment group as a founding member together with media behemoth Comcast (and others). This means that there will be more video and audio applications coming our way.

Linaro Ltd, the not-for-profit engineering organization developing open source software for the ARM® architecture, today at Linaro Connect Asia 2014 (LCA14) in Macau announced* that …

Allwinner Technology is a founding member of a new market segment group being formed in Linaro to focus on the Digital Home market. This group will be the third Linaro segment group, following the formation of the Linaro Enterprise Group (LEG), focused on ARM servers, and the Linaro Networking Group (LNG) focused on the networking equipment market space.

OS SUPPORT

The list from iTead should work as is. Others are compatible with the A20 SoC, but may require additional work to support the peripheral components.

REFERENCE

  • iTead Documentation and Download Repository [link]
  • Audiophile bit-perfect with the A10 [link]
  • CNX Software Blog. Developments on embedded computing, including news on Linaro [link]
  • Review of A20 built-in DAC and headphone output [link]

 

 

BEAGLEBONE BLACK: NAVIGATING THE AUDIO MAZE

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

linuxaudio2

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

LinuxAudio

And application can literally take any route through the different components in order to arrive at the hardware. An application can use Alsa, routed through Jack and back to Alsa; or it can use PulseAudio to OSS or Alsa all the way. Audio applications such as MPD can use either ALSA, PureAudio or OSS in order to appeal to a wider audience and provide compatibility to new, old and in-between versions and flavors of Linux.

FOCUS ON ALSA

In our quest for bit-perfect audio, A reasonable approach to simplify the audio path is by minimizing the number of components through which the audio stream can possibly travel.

A practical way to do this is to direct the application to use a single audio subsystem. In our case, restricting to ALSA looks like a good option since it is already included in the Debian BBB release. (At least PulseAudio and Jack are are installed when installing MPD)

This site [link] also has a good overview of the different sound subsystems in Linux. A graphical description of ALSA is as follows:

alsa

The key message here is that ALSA looks like a “simple” interface between an audio application and the hardware and that there is a Mixer (Sound Mixing) outside the Kernel that CAN can potentially be bypassed. And indeed it can be bypassed:

A sound developer who wishes to output sound in their application can take any of the following routes with ALSA:

  • Output using ALSA API directly to ALSA’s Kernel API (when sound mixing is disabled)
  • Output using ALSA API to sound mixer, which outputs to ALSA’s Kernel API (when sound mixing is enabled)
  • Output using OSS version 3 API directly to ALSA’s Kernel API
  • Output using a wrapper API which outputs using any of the above 3 methods

A further simplification is to restrict the use of ALSA through the ALSA API (a more modern API) and avoid using the OSS v3 API (Legacy API). This may not be an issue as modern applications do not have a need to use the older OSS v3 interface.

MPD (MUSIC PLAYER DAEMON)

Since Volumio and RuneAudio are using MPD, It is a good idea to select MPD and figure out how it works. MPD simply runs in the background playing music from its playlist. Client programs communicate with MPD to manipulate playback, the playlist, and the database. [link]

Configuring MPD to use ALSA

The mpd configuration file is at /etc/mpd.conf. (The default configuration for mpd -as installed for debian, uses ALSA.)

The MPD documentation [link] indicates that it is capable of outputting to 15 plugins (ALSA, PulseAudio, OSS, etc). The configuration file allow the selection of the output plugin. Here is the example for selecting ALSA as the output of MPD:

To configure an audio output manually, add an audio_output block to mpd.conf:

audio_output {
    type "alsa"
    name "my ALSA device"
    device "hw:0"
}

Further, the configuration allows us to disable and bypass any mixing/resampling of the audio data. I’ve highlighted in red the important parameters.

The following table lists the audio_output options valid for all plugins:

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.

CONFIGURING ALSA

According to these sites [link]. [link]

There are 3 configurations files that are read every time an ALSA device is opened:

  • Default configuration file (comes with ALSA and should not be changed): /usr/share/alsa/alsa.conf
  • System wide configuration file (optional): /etc/asound.conf
  • User configuration file (optional, residing in the users home directory): $HOME/.asoundrc

There is no need to write a configuration file since the default is always present. However, for our purpose we want to ensure that the data is sent to device without any mixing or resampling by ALSA

Recall from the ALSA-specific settings above:

It is recommended to use a “hw” or “plughw” device, because otherwise, libasound automatically enables “dmix”

Type=hw

Thus we wish to define a “hw” device. For our purpose we create a /etc/asound.conf file with the following entry:

pcm.!default {
	type hw
	card 0
}

The exclamation sign causes the previous definition of pcm.default to be overridden (so we don’t have to worry about the default configuration file /usr/share/alsa/alsa.conf).”card 0″ is the audio device we wish to use. It could be “card 1″ or other. See below to determine what to use. “type hw” is used as recommended.

If sample rate conversion is needed, we can use the “plug” type

Type=plug

Use the following entry in /etc/asound.conf

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

 

EXPLORING THE AUDIO COMPONENTS IN DEBIAN/BBB (KNOWN TO ALSA)

I used this guide [link] to explore and identify the different ALSA components in the Debian distribution for BBB

The presence of /proc/asound directory indicates that ALSA is present:

procAsound

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.

cards

The file /proc/asound/devices tells you the features of the cards. The native sound device is an audio playback device.

devices

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.

pcm

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

aplay-l

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″

hwparams

alsacap

alsacap serves to list the sampling rates, number of channels and sample formats supported by installed sound cards and their ALSA drivers.  This helps to find out which parameters do not require resampling (something to be avoided) and to troubleshoot ALSA problems [link]

However, the tool is only available as source so it needs to be compiled. Here is a sample output from here [link]

$ alsacap
*** Scanning for playback devices ***
Card 0, ID `SB', name `HDA ATI SB'
  Device 0, ID `VT1818S Analog', name `VT1818S Analog', 1 subdevices (1 available)
    2..8 channels, sampling rate 44100..192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'
  Device 1, ID `VT1818S Digital', name `VT1818S Digital', 1 subdevices (1 available)
    2 channels, sampling rate 44100..192000 Hz
    Sample formats: S16_LE, S32_LE
      Subdevice 0, name `subdevice #0'

 

ADDING A USB AUDIO DEVICE

Unlike a PC, a reboot is required for the system to detect the presence of a USB audio device.

After connecting a TI PCM270x-based device (USB 1.1)

ibasso

aplay-lUSB

After connecting DIYINHK  XMOS-based device (USB 2.0)

DSC_1310

aplay-lUSB2

After connecting AMANERO board (USB2.0)

DSC02497

aplay-lUSB-amanero

As can be seen, these cards are all automatically recognized by BBB.

ENABLING I2S OUTPUT

diyaudio’s MIERO has developed a driver to enable I2S output in the BBB [link].

It requires that the HDMI output be disabled (since it shares the same lines with Audio I2S). In my installation, the line to disable HDMI is already there as a comment, so I just had to un-comment it and reboot.

With HDMI disabled (and no other device in the USB port) -no sound cards detected:

aplay-lNohdmi

Here are the instructions (copied from the site) to download and install the I2S driver for BBB/Debian. You can just copy each line and paste it in the PuTTY windows (paste by clicking the right mouse button.

download and extract driver
wget http://bbb.ieero.com/botic_driver_v3.tar.gz
tar xvzf botic_driver_v3.tar.gz

install driver (assumes official BBB Debian release)
cp -av botic_driver/firmware /lib/
cp -av botic_driver/modules.bbbdebian/* /lib/modules/

update module dependencies
depmod -a

load driver (Needed after every boot)
echo BB-BONE-BOTIC1 > /sys/devices/bone_capemgr.*/slots

There are 3 configurations for the driver
BB-BONE-BOTIC1 - this is for BBB without cape
- onboard clock (48fs rates only)
BB-BONE-BOTIC2
- onboard clock (48fs rates)
- external clock (44k1fs rates)
- external clock switch on UART1_TXD (pin configurable via DT)
BB-BONE-BOTIC3
- external clock (48fs rates)
- external clock (44k1fs rates)
- external clock switch on UART1_TXD (pin configurable via DT)

aplay -l shows the following

aplay-lBotic

The I2S pins are the following:

I2SPins

TESTING WITH APLAY

Rather than testing with MPD which might invoke its resampler by default, we will use aplay (alsa player) which does not have a resampler of its own. It is a lightweight player for alsa.

I compiled a collection of tracks from 44KHz to 384KHz

aplayAllWav

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:

aplayErr1

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

aplayBotic44-1

aplayBotic44-2

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…

aplayBotic192-1

aplayBotic192-2

If playing 176KHz, ALSA resamples to 192KHz.

REFERENCES

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

BEAGLEBONE BLACK: ACCESSING NETWORK SHARE

2014/03/21 2 comments

ACCESSING NETWORK SHARE

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

  • Address of Airport Extreme: 10.0.1.1
  • 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”

cifs

2- mount the share with the following command

mount.cifs

  • mount -t cifs does the same thing (it invokes mount.cifs)
  • “//10.0.1.1/MUSIC” 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]

AUTO MOUNTING OF THE SHARE

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:

fstab-nas

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

BEAGLEBONE BLACK: ACCESSING uSD AND USB STORAGE

2014/03/19 5 comments

ACCESSING THE uSD CARD

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):

fdisk-l-noSD

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

fdisk-l-32MSD

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

fdisk-l-2GSD

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:

fdisk-l-beforeboot

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”

mount.card

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″

ACCESSING USB MEMORY STICK

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:

fdiskUSB

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.

AUTOMATING THE MOUNT PROCESS

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.

usbFstab

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:

fstab-card

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.

BEAGLEBONE BLACK: NETWORK AND WIFI

2014/03/18 2 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.

NETWORK SETUP IN DEBIAN

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

DebianEnet

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

etc-network-interfaces

And indeed, it is accessible though “10.0.1.101″ 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 192.168.7.2 as shown below:

BBBUSBandENET

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

resolv.conf

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

WIFI

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.

.tplink

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.

A BETTER APPROACH

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.

TPLinkClient

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.

etc-network-interfaces

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.

INSIDE

Found these photos here [here]

tl-wr702n_top-001

tl-wr702n_bottom-001

BEAGLEBONE BLACK: BASE OPERATING SYSTEM

2014/03/17 4 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.

INSTALLING S/W ON BBB

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 :-)

INSTALLING THE BASE OS: DEBIAN

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.

debian-logo

INSTALLING DEBIAN ON THE eMMC

  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)

Win32DI

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

DSC04373

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.

DSC04374

BOOTING

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.

CHECKING YOUR INSTALLATION

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:

OfficialDebianBBB

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: 192.168.7.2. It is a static address specified in /etc/networks/interfaces

BBBDebianIPAddr

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

OfficialDebianBBBdf

INSTALLING A SLIMMER VERSION OF DEBIAN

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:

BBBDebiandf

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.

REMOVING “UNNECESSARY” S/W

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]

Out-of-the-box:

OfficialDebiandf

After removing the above listed packages:

OfficialDebianBBBSlim1

REMOVING MORE S/W

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.

dfCompare

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.

slim3

OfficialDebianBBBSlim3

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

REMOVING PACKAGES

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)

BEAGLEBONE BLACK for AUDIO

2014/03/10 14 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
Comments
Native I2S support Yes Yes Both platforms can support I2S output, but it needs to be supported in the s/w.
I2S Sample Rate limitation Up to 192KHz (because the on-board clock is 19.2MHz) Only 48KHz family (because the on-board clock is 24.576MHz and integer clock dividers) BBB supports 48KHz, 96KHz, 192KHz and 384KHz. RPi supports 44.1KHz, 48KHz, 88.2KHz, 96KHz, 176.4KHz and 192KHz (in theory). RPi uses “fractional clock dividers” to generate the 44.1KHz sample rate family
Support for USB DAC Yes (LAN9512 chip [link]) Yes (Built-in in the main processor) USB in the RPi goes through a built-in HUB and it is shared with the LAN controller within the USB/LAN chip. USB in the BBB is natively supported by the main processor; LAN has a separate chip
Support for external, low jitter clocks Unknown Yes The master clock in BBB may be provided externally by disabling the on-board audio-freq clock.The Master clock in the RPi seems internally generated and there is no I/O pin to feed an external master clock
Master clock output No Yes (from on-board clock) The Master clock in BBB is provided by the on-board 24.576MHz and fixed at this frequency and can be directly accessed from the outside. The Master clock of RPi seems internally generated but un-accessible from the outside. Without Master Clock, you can only use DACs that can operate asynchronously without a Master Clock input such as the ESS DACs or DACs that can operate with the master clock = bit clock
Built-in rechargeable battery operation No Yes [link] Rechargeable Battery operation in BBB would disable the 5V supply to the USB. Thus for USB operation, where the USB adapter takes the power from USB, BBB must be powered with 5V DC
Built-in Storage No 2 GB eMMC Flash BBB can boot from the internal storage freeing the SD card for music storage. RPi requires that the OS be stored in the SD card (although it may be possible to also store music in the SD card)
Looks Medium Good :-)

In addition, even though the Rasberry Pi has the most community development support, the BBB is a close second, so there is ample resources available. The s/w part is a big part of the solution.

BEAGLEBONE BLACK

CPU: AM335x 1GHz ARM® Cortex-A8

DSC04362

DSC04367

DSC04365

RAM Chip (512M DDR3)

DSC04364

Flash Storage Chip (2GB 2MMC)

DSC04367-001

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

DSC04363

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

DSC04368

DSC04369

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”

usbHostSch

“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

DSC04361

AudioClock

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.

SlaveMode

The I2S Pins are as follows on the header P9 (clearly labeled on the board) [link]:

I2SPins

There is a good discussion on I2S audio output here [link]

EXTERNAL CLOCK BOARD

I don’t know about the “unfortunately” part above, but for audio, disabling this clock and having access to the clock line through GPIO3_21 allows the use of an external clock (so this turned out to be fortunate for audio applications).

The solution for bit-perfect audio for all sample rates is to provide the clocks externally through an expansion “cape”. This cape would have two clocks: one to support the 44.1KHz family of frequencies and another to support the 48KHz family of sample frequencies. Two other I/O pins  are used to select the appropriate clock frequency. In addition to an external clock board, s/w needs to be developed to enable this function. More discussion here: [link], [link].

This “external clock board” is currently being discussed here

It is important to reiterate that without this not-yet-available clock cape, the BBB would not be able to support the 44.1KHz family of sample rates through its I2S interface. In the meanwhile, while we await the development of the dual clock board, the USB interface would be the preferable method for audio output.

GETTING STARTED

The first thing to do is to check the board and ensure it is working. Follow the Getting Started Guide [link]. Here is what you do:

  • To get started all you need is to connect the BBB board to a computer with the included USB cable. This will power the board and provide an interface to the board
  • The BBB comes already loaded with an operating system (currently Angstrom) in the on-board eMMC flash memory. Once you power it on, it will boot-up.
  • After boot, you will see the BBB board as a storage drive in your computer. From power-on, this booting process takes about 24 seconds.
  • Following the link the the “Getting Started Guide” install the device drivers that will enable “network-over-USB” access to your BBB board
  • Type http://192.168.7.2 in your browser and you will see the following screen

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

BBBDrive

BBB after installing network-over-USB drivers (address: http://192.168.7.2)

BBBWeb

Terminal Session

You may want to access the BBB with a terminal session. Download “putty” [link] (for Windows) and run it. Enter BBB IP address (192.168.7.2), you will see a log-in prompt. Enter “root” for login and nothing for password.

BBBPutty

BBBPuttyLogin

BBBPutty2

The official getting started guide is here: [link]

CUBIEBOARD FOR AUDIO?

2014/03/07 14 comments

We’ll explore bit-perfect I2S output in the Cubieboards…

There are two current versions of the boards: Cubieboard2 ($65) and Cubietruck ($95) [link]. Both boards are based on the Allwinner A20 dual core processor.

A20 I2S SUPPORT

According to the A20 datasheet (p.20) [link] the chip supports up to 8 channels of I2S output: DO0 to DO3 represent the 4 stereo channels of I2S data.

A20I2S

The A20 User Manual describes the block diagram for I2S: The clocks for I2S are all based on “Audio_PLL” Master Clock.

A20Digaudio

Audio_PLL is the audio frequency clock derived from the 24MHz system clock. The PLL generates the 24.576 MHz and the 22.5792 MHz clocks. This means that the A20 is capable of bit-perfect playback for both the 44.1KHz and 48KHz family of sample rates.

A20AudioPLL

The specification also lists the supported sample rates (44.1KHz to 192KHz) and the supported Fs

A20supportedSampleRates

In Summary, the A20 processor has excellent support for I2S. All sample rates from 44.1Khz to 192Khz are supported. The processor generates the required Master Clock frequencies of 24.576 MHz and 22.5792 MHz through standard PLL processing.

CUBIEBOARD2 I2S PINS

According to the schematics [link] we find that the I2S pins are not connected to the expansion headers. PB5, PB6 and PB7 which are the Master Clock, Bit Clock and LR Clock are not connected.

Therefore, there is no support for I2S in the Cubieboard2

cubie2I2S

CUBIETRUCK I2S PINS

According to the schematics [link] we find that the I2S pins ARE connected to the expansion header C9. Notice that some jumper/resistors may need to be installed/removed.

CDI2SPins

In the lower part of the diagram (left side) shows the I2S signals corresponding to PB5-PB8 above. Shown also are the resistors/jumpers that are to be installed or removed in order to connect to the right side. Those connections corresponds to the CN9 header pins 18, 20, 22 and 24.

Notice that the default connection to pin 18, 20, 22 and 24 of header CN9 is to the TVIN signals (TVIN0 to TVIN3). In order to use the I2S signals, the jumpers need to be removed from the TVIN signals and installed in the I2S signals (I2S-MCLK, BT-PCM-CLK, BT-PCM-SYNC and BT-PCM-OUT)

Thus the I2S signals can be made available as follows:

  • Pin 18 of CN9: Master Clock
  • Pin 20 of CN9: Bit Clock
  • Pin 22 of CN9: LRCK
  • Pin 24 of CN9: Data Out

CTCN9

According to this post [link]. The modification to the resistors/jumpers are as follows:

remove R175 and set R174
remove R177 and set R176
remove R178 and set R179
remove R180 and set R181

(Only need to modify these for stereo I2S)
remove R183 and set R182
remove R185 and set R184
remove R187 and set R186
remove R189 and set R188

R175 to R181 are for the left side of CN9. Those connectors are for multichannel I2S. So for Stereo I2S only modding R182 to R189 are required.

You can see the surface mount resistors that need to be modified in the following photo and diagram.  Seem pretty easy to mod.

Another option is just to connect a wire to the appropriated resistor pad and leave the resistors in their original position.

cubieTruck2 CTRs

One more observation: Cubieboards are developed by a team of young engineers…

DSCN9853

SUMMARY

The A20 processor has excellent support for bit-perfect I2S digital audio. However, only the CubieTruck board allows access to the I2S pins.

REFERENCE

Audio discussion on Cubie Forum: [link]

Low Cost Audiophile Music Servers

2014/03/01 14 comments

DIY Audio is getting a huge boost from two recent developments in the form of RuneAudio and Volumio which run on low cost hardware such as the Rasberry Pi and the BeagleBone Black. This new breed of music “appliances” constitute a step forward for music reproduction because they operate on  simpler single-board computers where the OS can be highly optimized for (only) music reproduction and stripped of all other unnecessary tasks.

Note: there are earlier implementation of multimedia software on these platforms -such as XBMC on Rasberry Pi-, but here we have audio-only implementations.

Both teams were working together and created the custom user interface, but due to some “chemistry mismatch” they split a while back. It is good to see however, that there is mutual respect and healthy competition between the teams resulting in better products ultimately benefiting the end user. You can read more here [link] and here [link].

As of this writing, the two projects share a common user interface (soon to diverge into their own versions), but use different UNIX flavor in their OS internals. Both use MPD [link] as the music server application.  Currently, Volumio supports I2S output, whereas RuneAudio will have I2S output in the upcoming 0.3 release.

USB INTERFACE TO THE DAC

The more “mature” way to interface the music server to a DAC is through its USB interface. I say “mature” because these interfaces have been available for a while and there are many solutions where in order to support bit-perfect playback, the audio clocks (the 44.1KHz and family; the 48KHz and family of frequencies) are generated by dedicated on-board oscillators.

However, there is still the driver consideration. Theoretically these interfaces should be supported by the OS (which are all Linux derivatives) without installing device specific drivers; but in practice this may not be the case. Here are potential interfaces: [link]

I2S INTERFACE TO THE DAC

The second way to interfacing to the DAC is through I2S which is a very appealing option because it “does away with another component” resulting in an even simpler solution: just the single board computer and the DAC. There is no need to transfer the audio data through the USB interface. The main concern here is whether or not the platform is capable of bit-perfect playback. Lets explore these in more detail.

BeagleBone Black (BBB) I2S output

BBB audio is generated by the main processor, the AM335x 1GHz ARM® Cortex-A8. The Multichannel Audio Serial Port (McASP) subsystem is responsible for generating the audio using and external audio frequency oscillator. In this case it is a 24.576 MHz oscillator connected to the clock input pin of the processor’s audio subsystem (See page 75 of the BBB System Reference Manual [link])

DSC04361

6.10.6 Audio Interface

There is an I2S audio interface between the processor and the TDA19988. Stereo audio can be transported over the HDMI interface to an audio equipped display. In order to create the required clock frequencies, and external 24.576MHz oscillator is used.

In order to create the correct clock frequencies, we had to add an external 24.576MHZ oscillator. Unfortunately this had to be input into the processor using the pin previously used for GPIO3_21. In order to keep GPIO3_21 functionality, we provided a way to disable the oscillator if the need was there to use the pin on the expansion header.

Because there is only a 24.576MHz clock, only the 48KHz family of sample frequencies can be supported. Seems audio (or bit-perfect audio – or perhaps “legacy 44.1K audio”) was not a big concern for the designers of the BBB. HDMI, which defaults to 48KHz audio was the primary concern.

Notice that If playing high res music, it can support 96K, 192K and also 384K (24576000/64=384000Hz)

Fortunately, GPIO3_21 is an expansion pin accessible from the outside and the on-board oscillator can be disabled by s/w.

The solution for bit-perfect audio is to provide the clocks externally through an expansion “cape”, using one or two other I/O pins to select the appropriate clock frequency (and the s/w driver that would enable the use of the external clocks) More discussion here: [link].

Rasberry Pi I2S output

There are some hits that the RPi is capable of of 44.1K output in the I2S interface. I can’t find a definite reference of bit-perfect playback. If I had a RPi I would just hook it to one of my ESS DACs and observe the actual sample frequency. Several I2S DACs have already been developed that seamlessly plug into the RPi expansion headers [link].

But is the RP1 I2S bit perfect?

In the RPi, the audio is generated by the Broadcom BCM2835 [link]  peripheral SoC chip. The audio frequencies are generated through an 0n-board 19.2 MHz oscillator. (Photo from here [link]).

RPIosc

If applying integer division to the clock, exactly 48KHz (and its family) can be supported. However, the highest sample rate that can be supported is

19200000/64=300KHz or effectively 192KHz.

According to the Datasheet, the Audio system is driven by a master clock “PCM_MCLK”. According to this thread [link], seems this master clock is generated internally by the clock generators. According to the Datasheet, the clock generators can use “fractional clock dividers”. The Datasheet indicates:

6.3 General Purpose GPIO Clocks

The General Purpose clocks can be output to GPIO pins. They run from the peripherals clock sources and use clock generators with noise-shaping MASH dividers. These allow the GPIO clocks to be used to drive audio devices.

The fractional divider operates by periodically dropping source clock pulses, therefore the output frequency will periodically switch between:

frequency source /DIVI & frequency source /DIVI+1

Jitter is therefore reduced by increasing the source clock frequency. In applications where jitter is a concern, the fastest available clock source should be used. The General Purpose clocks have MASH noise-shaping dividers which push this fractional divider jitter out of the audio band.

Thus, fractional dividers can be used to generate the 44.1K frequencies (or rather 44.1Kx64 for the bitclock) by using the above built-in method. Audiopurists would cringe at the “periodically dropping source clock pulses” part.

No master clock output in RPi

According to the Broadcom BCM2835 datasheet (pp. 119-120),

The PCM audio interface has 4 interface signals:
PCM_CLK – bit clock.
PCM_FS – frame sync signal.
PCM_DIN  – serial data input.
PCM_DOUT – serial data output.

In clock master mode (CLKM=0), the PCM_CLK is an output and is driven from the PCM_MCLK clock input.

In clock slave mode (CLKM=1), the PCM_CLK is an input, supplied by some external clock source.

This lack of master clock output can also be seen in the P5 header of the RP1 [link]:

RP1P5

And Also as indicated from the developers of RP1 DACs [link]

What about the SCLK (MCLK) signal on DAC chip?

The Raspberry Pi (RPi) does not provide such a signal, it outputs just the other I2S signals: LRCK, DATA and BCK, but not a system clock.

The PCM1794A works well if the SCLK (MCLK) signal is connected with the BCK signal which is done on the RPi-DAC board via a jumper (SCLK is BCK).

The PCM_MCLK is the master clock and it seems internally generated. There is no other reference to PCM_MCLK in the datasheet. The bit-clock (PCM_CLK) is the reference clock used for I2S.

RPi Jitter numbers?

According to this post [link], there is a single phase jitter data point of -54 dBc/Hz at 100 Hz (for a carrier frequency of 1.411 MHz, which is the sample rate for 44.1KHz/16bit). What does this mean?

Typically one would see phase jitter plots for clocks and typically at the source frequency (e.g. 24.576Mhz, etc). Here is a phase jitter value of the bit-clock. In the case of RPi, this clock is derived from the 19.2MHz and scaled by “fractional clock divider”

I was able to find a phase jitter plot from Audiophileo [link]. There the phase noise of the device is compared against the phase noise of the device with a “jitter simulator” turned on. The carrier frequency is 2.822 MHz, which is the frequency of 44.1KHz/32bit. This frequency corresponds to the bit-clock, so hopefully this is a fair comparison.

The plot below is the plot from Audiophile0 with the phase jitter value of -54 dBc/Hz at 100 Hz superimposed. I followed the same slope as the other curves and extrapolated to 1 Hz. Then I used a jitter calculator to find the RMS jitter [link]. The result is shown below. The jitter value for the RPi is the green dotted line. The pink line represents the added jitter to the Audiophileo native jitter which is shown in the blue line.

RPiJItter

WHICH PLATFORM?

The two most popular (and lowest priced) boards are the Rasberry Pi (RPi) and the BeagleBone Black (BBB). Here is a nice comparison of the two boards [link].

Here is my comparison for audio (please comment if you see any inaccuracies).

Parameter Rasberry Pi
BeagleBone Black
Comments
Native support for 44.1K and family Yes, through “fractional clock dividers” No It remains to be seen how much jitter is introduced by the “fractional clock division” of the RPi
Native Support up to 384KHz No. On-board clock is 19.2MHz Yes. On-board clock is 25.576MHz RPi can support up to 192K material
Support for USB DAC Yes (LAN9512 chip [link]) Yes (Built-in in the main processor) USB in the RPi goes through a buil-in HUB and it is shared with the LAN controller within the USB/LAN chip. USB in the BBB is natively supported by the main processor and LAN by a separate chip
External Clock capability ?; likely not Yes The master clock in BBB can be provided externally by disabling the on-board audio-freq clock. The Master clock in the RPi seems internally generated
Built-in rechargeable battery operation No Yes [link] Rechargeable Batt operation in BBB would disable the 5V supply to the USB. Thus for USB operation, where the USB adapter takes the power from USB, it must be powered with 5V DC

SUMMARY

I’d say that the current best option for audio is through a USB-I2S device until the clock issues are better understood. The current best option for a computing board is the BBB primarily because it can support (or more likely to support) and external clock board. If you already have RPi/I2S-DAC and are happy with it, that’s what really matter…

ADM7150: New (Low Noise) King of the Regulators

2014/02/26 5 comments

ADM7151

Analog Devices introduced a new 800 mA LDO with the lowest noise figures [link]:

  • RMS Noise: 1.6 μV (10 Hz to 100 KHz)
  • Noise Density: 1.7 nV√Hz (10 kHz to 1 MHz)
  • Available in diy-friendly SOIC packages
  • Price: ~$8 (quantity 1). The LT1763, also available in SOIC is ~$4

Here is comparing noise figures with other “favorite” regulators. Also, check out the table summary [link].

ADM7151Noise

The low noise performance has been accomplished with a “new architecture” for linear regulators where the reference is first amplified and then buffered by a trans-impedance amplifier and filtered with an external capacitor [link, minute 34:30] The noise of the regulator can be further reduced by increasing the size of the bypass cap beyond the value recommended in the datasheet.

Here is an interesting graph [link] [link] showing the effect of the size of the bypass capacitor on the noise of the regulator. Notice the use of large value capacitors up to 10,000 uF (which is only practical for us diyers :-)).

From the datasheet:

The BYP capacitor is necessary to filter the reference buffer. A 1 µF capacitor is typically connected between BYP and GND.

Capacitors as small as 0.1 µF can be used; however, the output noise voltage of the LDO increases as a result. In addition, the BYP capacitor value can be increased to reduce the noise below 1 kHz at the expense of increasing the start-up time of the LDO.

Very large values of C BYP significantly reduce the noise below 10 Hz. Tantalum capacitors are recommended for capacitors larger than approximately 33 µF. A 1 μF ceramic capacitor in parallel with the larger tantalum capacitor is required to retain good noise performance at higher frequencies. Solid tantalum capacitors are less prone to microphonic noise issues.

adm7150By

More discussion at diyaudio [link] including comments from people involved in the design of the regulator

Follow

Get every new post delivered to your Inbox.

Join 183 other followers