I received the new Beaglebone audio cape from CircuitCo this week, and wanted to share my experience, since documentation for this board is really not very good (Edit on the 21st of June: …but getting better all the time!). Hope this will be useful for you!

The BBB Audio Cape version B1

This is a revision of the audio cape which uses far fewer components – the card looks empty – and is based on an AC3104I chip, the  TLV320AIC3104. It is now, as of June 2014, starting to become available through boardzoo, though shipping from that site is ridiculously expensive even in the US!

This audio cape simply adds a DAC and an ADC to the built-in audio capabilities of the Beaglebone. This means that the resulting “sound card” is split between native Beaglebone capabilities and the add-ons chips on the cape. OK, there is a little bit more to it such as signal processing, mixing and so on, but at a high level, this is really what it is. Just so you know…

What are the characteristics of the cape? Glad you asked:

  • One Stereo ADC / One Stereo DAC
  • Up to 96kHz sample rate
  • 6 inputs, 6 outputs – fairly advanced mixing capabilities that are exposed through ALSA, more on this below. You can only use one stereo input and one stereo output at a time, since there is only one stereo ADC & DAC.
  • One stereo line in – mic jack (blue)
  • One stereo headphone output  jack (green)
  • One expansion header: Line out stereo

Some of the features of the codec that are not leveraged here, are the possibility to bias the mic (chip supports it, not implemented on the board), and headphone detection (same). Basically, we are getting the simplest possible implementation of the codec.

Anyway: once you receive the audio cape, you can plug it into your BBB, and start working. This is where it gets complicated.

Basic software installation

Software distributions tested: Ubuntu 14.04 LTS and Debian Wheezy demo images available on

Out of the box, your BBB will not detect the audio cape: as of June 2014, none of the official BBB distributions support it out of the box. That said, the cape will never be automatically detected anyway, because it is not equipped with an EEPROM, so the BBB does not have a way to identify it.

I suppose this was done to lower the BoM, but it is kind of a pity not to take advantage of this pretty efficient mechanism. My other disappointment with the board is that its audio connectors are suface-mount types. This means they are fragile. CircuitCo noticed this and added a drop of glue to reinforce them, but the right way of doing this would have been to use through-hole connectors. Anyway…

You are therefore stuck with compiling a device tree overlay for the board, and load it yourself. Go to the official cape page, and download the DTS file. Then compile the overlay:

Of course, it’s not that easy: even if you “apt-get install device-tree-compiler” beforehand, you will find that the DTC version that is shipped with the Debian or Ubuntu images on is too old and does not support the “-@” switch. I have attached a more recent version just below, it will save you time and effort. That one works on the current Debian and Ubuntu distributions.


Once the overlay is compiled ( BB-BONE-AUDI-02-00A0.dtbo ) , place it in /lib/firmware.

The audio cape makes use of the I²S interface of the BBB, but that interface is also used by the built-in HDMI virtual cape. You therefore need to prevent loading it at bootup. Alternatively, you can try to identify the slot of the HDMI cape: cat /sys/devices/bone*/slots and find the slot number of the HDMI cape – let’s say “5” in this example –  then, as root, do a “echo -5 > /sys/devices/bone*/slots” . If you are lucky, the driver will unload. If you are not lucky, and really, it’s a bit random, you will get a kernel panic. So the good solution is:

  • Edit /boot/uboot/uEnv.txt
  • Add the following boot argument:

  • Reboot the board (sudo shutdown -r now)

There is also a “HDMIN” overlay, my understanding is that the “N” stands for “No Audio”: so keep that overlay, you will still be able to use the HDMI out of the BBB.

Note that once the board reboots, the HDMI cape is still present in the “slots” file, because the Beaglebone detected it through its eeprom. But its driver is not loaded – at least if you followed the instructions above – so there is nothing to worry about.

Almost there!

Now that the board has rebooted, you can load the audio cape overlay:

If all goes well, the overlay will load and your BBB will now have audio capabilities. You can check this by noticing that there is now a new “/dev/dsp” device in the /dev/ tree.

But why make things easy? “Having audio capabilities” unfortunately means that you now have to dive into the nightmare that Audio is on Linux, and believe me, it’s bad. I have nearly 20 years of Linux experience, scary as it may seem, so I do have a bit of a historical view on all this, but audio on Linux has always been a mess, because people have tried to make it better year after year by adding layer upon layer of APIs, and the result today is pretty horrendous.

Sorry if I offend anyone by stating this, but hey, what does this look like (not sure where this image comes from, it exists on multiple locations all over the internet and is a good way to scare people):



With that said, let’s get our hands dirty:

Making audio actually work on the BBB

Before running the steps below, one word of warning: this assumes you are starting from a clean system. If you played with audio before and already have stuff like pulseaudio, jack and so on installed, please remove everything (apt-get remove –purge) before going further, you won’t waste time debugging tons of flaky interactions…

Nowadays, “alsa” is pretty much the most accepted audio API on Linux. Not that alsa is the only one, mind you. But you will pretty much have to install alsa on your system if you want to do anything with it:

This will install a few extra packages that are required to support audio. Once alsa is installed, let’s see if it detects our new audio cape:

Yes! We can move on and test further: let’s do a few sound checks:

This should play noise in your left then right ear.

A slightly better example:

will play a tone rather than noise. But it should not be very loud at that point.

Mixer controls:

Before you get a headache listening to the two examples above, let’s get familiar with the audio mixer. You probably already have noticed that audio was not very loud by default: you can use the text-based “alsamixer” to adjust volume.

Using alsamixer, you will see that you are getting dozens of controls, way more than you should ever see as a normal user. This is apparently because the audio driver developers wanted to give maximum control to users, why not. At first, this is just confusing, to be honest. Here is what I use:

  • PCM : a sort of master volume output control
  • HP:  mute control of the green jack (use “m” to toggle)
  • HP DAC: volume control of the green output jack
  • Left HP and Right HP: mute control of left and right channels

There are tons of controls over there: De-emphasis, AGC with fairly configurable attack and decay settings, and lots of mixing options.

At the end of the day, though, you won’t get beyond the fact the codec only has one stereo DAC and one stereo ADC, so you will only ever get two channels at a time, that’s it.

Useful software for playing audio

This is where I lost lots of time, because tons of software that ships on the BBB (I’m talking about the official Debian image, and the Ubuntu 14.04 LTS image on does not actually work well, leading you to think something is broken at a lower level.


  • mplayer (use the alsa output driver)
  • aplay


NOT working – sound output garbled, or crashing, or no audio -:

  • mplayer2 – outputs lots of error messages, no audio
  • mpg123 – destroys your ears if you were wearing headphones at a high volume by playing raw digital data, or at least it’s what it sounds like.

Recording audio

For me, recording out of the box just plain didn’t work properly – let me know if this works different for you.

Basic recording command to test:

By default, the sound was very faint, no bass, lots of hiss – using a good audio cable, and the audio output from my phone.

I used this one-liner to play the audio from the input to the output of the card while I experimented with the mixer:

Then I launched alsamixer from a different terminal. After lots of experimentations, I discovered that the mixer requires – at least in my case – adjustment of the following controls in the “playback” tab:

  • Right PGA Mixer Line1L
  • Right PGA Mixer Line1R
  • Right PGA Mixer Line2R
  • Right PGA Mixer Mic3L
  • Right PGA Mixer Mic3R


  • Left PGA Mixer Line1L
  • Left PGA Mixer Line1R
  • Left PGA Mixer Line2L
  • Left PGA Mixer Mic3L
  • Left PGA Mixer Mic3R

One word of warning here: do not mute all entries simultaneously in either group. This will crash the audio driver and will force you to reboot or reset.

What worked properly for me was the following: set everything to MUTE, except:

  • Left PGA Mixer Mic3L
  • Right PGA Mixer Mic3R

If you play with other combinations, you can simulate a mono input (use Mic3L or or Mic3R on both Left and Right PGA Mixers). Enabling only the Line1 or Line2 controls gave me super low input levels on the audio input.

Mic3 – I suppose – uses a microphone amplifier, so you get much higher input levels, and you make sure you don’t saturate the input. Use a reasonable input signal volume, and adjust with the “PGA” control in the recording controls.

Additional mixer controls

There are additional controls you can use on Alsamixer, that can come in handy depending on what you are using the audio cape for:

  • ADC HPF: High pass filter. Removes very low frequencies from the audio input. Useful if you use the sound card as a SDR I/Q input and want to remove ground hum
  • ACG : on/off control, this is an automatic gain control for the sound input
  • De-emphasis: not quite sure about that one

Advanced usage

These are notes on using the card in specific scenarios where I had to work out a few issues. As usual, feedback is welcome and appreciated:

Using for analog I/Q input

Proof that you can have the audio cape and LCD working at the same time!

Proof that you can have the audio cape and LCD working at the same time!

I have used the audio cape for doing signal processing using the analog IQ output of my radio. It seems that the cape’s audio codec – or is it the BBB hardware? – exhibits a fairly common issue of “one sample shift” between the left and right channels. The symptom is that your FFTs will show a limited mirror effect around the center frequency. If you really see both sides of the FFT being exact mirror images of each other, this is another issue, probably you are not processing a stereo but a mono signal.

In order to fix this lag, you will have to delay the right channel by exactly one sample before doing any processing. Once this is done, your waterfall will look good.

A useful setting for I/Q input is the ADC HPF filter, which you will want to activate at its lowest setting, in order to get rid of the 0Hz peak.

Playing nice with other capes

At first sight, it looks like the Audio cape does not play well with the various LCD capes that exist, because it reclaims some GPIOs that are used by the buttons of those capes. Looking closer, it actually looks like those GPIO claims are just cruft from the A version from the Audio cape, which drove LEDs on those pins.

I therefore went ahead and removed the claim from the overlay: dirty, but worth a try, right ? And guess what? It kinda works : just delete line 26 in the DTS (   “gpio1_18”, “gpio1_19”, ) and recompile the DTS: the cape manager won’t complain about anything anymore, and the audio cape will work, as well as the screen. This opens all sorts of possibilities, such as playing movies:

Playback does use a lot of CPU, but is actually pretty smooth as long as you “framedrop”. I didn’t try to play full HD stuff though.


Next steps

If you have any sort of input on the above ( additional software that you find useful, more info on mixer controls, etc) please get in touch, I will improve this article.

Also, if you want to help making the audio cape work with the LCD capes, please also contact me!

18 comments on “Beaglebone Black audio cape

  • June 6, 2014 at 19:30

    Please note that the device tree file is being included in the next release of the debian image along with some scripts to make loading them easier. Please also note a complete redesign of the LCD capes is in progress which will make them compatible with all of the newly released capes including the audio cape revB…

    • June 6, 2014 at 19:34

      That’s great news David, thanks! It looks like the incompatibility is really skin-deep, I was able to modify the DTS and have both the Audio Cape and LCD cape work well together, I need a bit of time to document it above. Not 100% sure why gpio1_19 is claimed by the Audio cape? I suspect a legacy thing here, such as the LEDs on the previous audio cape version, but I have not compared the schematics yet…

    • June 6, 2014 at 20:10

      very good point, my bad -> that link is kind of lost above all the additional instructions below it, I totally overlooked it…

  • June 30, 2014 at 18:58

    The audiocape cannot provide plug-in power for microphones can it?

    • July 1, 2014 at 09:44

      Yes, that’s correct.

  • August 27, 2014 at 07:06

    What software did you use to generate the LCD image? Is that doing an FFT straight up in software using the CPU on the BB, using the DSP core, or in hardware in some way?

    • August 27, 2014 at 16:38

      I just used software FFT – using Python, not optimized whatsoever… I am quite sure performance could be really good with a good hardware-based FFT, but I have not investigated. Yet.

      • September 25, 2014 at 16:15

        Is there a particular graphics library that you used to create the image of the waveform itself, or did you roll everything yourself?

  • November 7, 2014 at 22:37

    Thank you for such a thorough writing on how to get this working. If this works, and I get my hands on the hardware, you will have been a total life-saver!

  • November 7, 2014 at 23:11

    Judging from the chipset number it’s using, this seems to be newer? Hope it works. I just ordered one 😉

  • November 27, 2014 at 05:11

    Thanks. Very helpful post. I am looking for some means to get 4x audio input channels easily (synchronous sampling across all four channels – i.e. no channel-to-channel delay), without resorting to building my own hardware for speed. Any ideas?

  • June 11, 2015 at 00:45

    Do you know if it is possible to stack audio capes for multichannel input? i.e. stack 3 boards, use the stereo IN for 6 inputs, and then process them simultaneously instead of having to multiplex them? (and then output a stereo signal through one of the boards)

  • June 11, 2015 at 11:46

    i can’t find where buy this audio cape revB for beaglebone black, i only find revA is bought popular but not compatible with BBB.
    Can U give me where i can buy it! thanks a lot!

  • July 1, 2015 at 20:05

    I have a Debian BBB and installed the DT overlay as instructed, plus disabled HDMI and verified the overlay is listed in the slots file. aplay -L shows the EVM device. But when I check pin P9_28 with a scope it’s dead. Any suggestions on debugging why the AUD_DOUT pin on my BBB is not being driven when I play a sound (speaker-test, for example) on default:EVM?

    There are so many software setup steps… and if any goes wrong it probably derails the whole process… hard to debug!

  • July 25, 2015 at 05:57

    dear all! i want beaglebone black can work compatable with audio cape A1, but almost insformation I search on Google say that this cape can’t work with BBB. Can you give me some why reasons? and maybe, please give me solution to define software and hardware to BBB and this cape good word each together. Thanks all!


Leave a Reply

Your email address will not be published. Required fields are marked *