I2S Audio on the BBB

Skip to first unread message


Jan 3, 2017, 11:57:29 AM1/3/17
to BeagleBoard
I spent most of the weekend down in the rabbit-hole, trying to get a
CircuitCo Rev_B Audio cape to work, (unsuccessfully.)

Is this cape compatible-with / supported-by Debian 8.6/kernel 4.4 ?

Does the BB-BONE-AUDI-02-00A0.dtbo overlay that comes with the current distribution work?

How can you tell if an overlay actually loaded, with 4.4? 
as well as the boot log, only shows the first physical four, and no longer shows the higher numbered "pseudo-capes" and overlay status.

I understand that
The CircuitCo cape does not have an EEPROM, so everything needs to be configured explicitly.
I need to use a base .dts with HDMI audio disabled, then load the overlay for the CircuitCo card.
I also need to load the asound.state file.

Am I approaching this correctly?

I can not use a USB-soundcard for audio. I have several applications
that need McASP/I2S running for several other codecs, but I thought I would start 
with the CircuitCo cape as a starting point.

--- Graham



May 15, 2017, 7:11:11 PM5/15/17
to BeagleBoard
I'm also interested as I have a project where I will interface directly to the I2S/McASP interface. Did you figure it out?


May 15, 2017, 9:46:50 PM5/15/17
to BeagleBoard
Yes, I was able to get a CircuitCo Rev.B Audio cape running, using the I2S/McASP interface.
I'll write it up for you, if you are interested.

If you are going to use a different CODEC or other device on the I2S/McASP interface,
you will need to see if a driver already exists for it, or if it fits a generalized I2S audio interface that
is already inside the kernel can be invoked and controlled from a device tree.

If it is unique, then you will have to write your own Linux driver and recompile the kernel.

If you just want audio, it is a lot easier to just use a USB CODEC.

--- Graham



May 16, 2017, 11:51:19 AM5/16/17
to BeagleBoard
I would appreciate the writeup, thank you.

My project requires interfacing to an IC with I2S input. I planned on using (something like) aplay to write audio out to I2S/McASP channel (using built-in driver support) and hoped I could also use the built-in support (drivers) for SPI and/or I2C using the /dev/spidev<x.y> or /dev/i2c-<n> devices to control the IC.


May 16, 2017, 2:21:30 PM5/16/17
to BeagleBoard
It will be a day or so, but I will post the write-up here.

You will not be able to control the IC independently, since the kernel claims the device.
The Linux audio system expects to be able to control the audio controls such as volume, etc.
by reaching into the CODEC through the control bus.  The kernel blocks direct user
space access to the device.

In fact one way to make sure the device tree loaded correctly is that the "UU" symbol
appears at the devices' I2C address.

--- Graham



Dec 21, 2017, 9:19:21 AM12/21/17
to BeagleBoard
This is very old, but I'm still interested in using I2S to directly drive an audio device (software defined radio module).
Could you post your write-up if available? Thanks.


Dec 21, 2017, 10:40:30 AM12/21/17
to BeagleBoard
I need to gather it together and do some edits, so it makes sense.
It will be a few days or so.
--- Graham



Dec 26, 2017, 3:54:04 PM12/26/17
to BeagleBoard
Here it is.
--- Graham


Making the Audio Cape Work                                          2017 MAY 15

My goal was specifically to make a CircuitCo Audio Cape Rev.B work, driving an
amplified speaker system, and then operate the BBB as an "Internet Radio."

The CircuitCo Audio Cape is no longer in production, so may be difficult to
find.  It uses a Texas Instruments TLV320AIC3104 Codec.  The same driver may
work with other cards that use the same CODEC, or other CODECs in the same
TI family that use the identical I2C commands to configure the CODEC.

If you want to use a different CODEC, then you will need to research whether 
there is a Linux driver for that specific CODEC, and figure out how to invoke
it from the device tree. If you are lucky, there may be one.  If you are not 
lucky, then you will have to learn about writing your own Linux device driver.

Hardware Note:
    The CircuitCo card does not appear to have any supersonic filtering.
    It needs a supersonic RC low pass.
    The noise starts about 150 kHz, peaking at 625 kHz

If you put a scope on the output, with the audio at reasonable volume level,
you will see a bunch of Delta-Sigma leakage that is louder than the desired audio.  
You can not hear it with your ears, but could cause problems with circuits that
are sensitive in that frequency region, with the chance of unexpected amplifier
overload and distortion, for no apparent reason.


I used Debian 8.6 Release 2016-05-11, iot, SDcard resident, in case I wanted to
store a lot of music files.

rm /uEnv.txt        # backwards compatibility

edit uEnv.txt:
    cmdline=coherent_pool=1M verbose

apt-get update
apt-get install git alsa-base alsa-utils mpd mpc

Expanding partition to full card size
    cd /opt/scripts/tools/
    git pull
    sudo ./grow_partition.sh


sudo update-initramfs -uk `uname -r` 

to make sure the *.dtbo get's copied to the intrd. (it'll still read 
it from the /lib/firmware) 

otherwise, dmesg | grep cape 


You can check the existence of a soundcard by looking in /proc/asound/cards. 
For example:

 bash$ cat /proc/asound/cards

aplay -l  or  aplay -L

Get Robert's asound.state file from
Download the asound.state file to  /var/lib/alsa/asound.state

cat /var/lib/alsa/asound.state
check to see that the 'cape' is loading:
look in the boot 'spew' for
[   ] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-BONE-AUDI-02' VER 'N/A' PR '0'


check if the CODEC can be accessed via I2C interface:
i2cdetect -y -r 2
should show the chip at address 0x18 for Audio Cape Rev.2

If all the device tree files loaded, will show 0x18 as protected 'UU'
Meaning the kernel has claimed the CODEC, and is now in control.
You can no longer access the CODEC from user space

If you want to dump the CODEC I2C configuration (I2C page 0)
i2cdump -f -r 0x00-0x7F -y 2 0x18

When I first got to this point, I thought the CODEC was not working, but it
turns out the default gain levels are extremely low, and it was actually working.
Turn up the volume before you get discouraged.
Configure the Codec using amixer

In the default routing:
amixer set 'HP DAC' 0           # 0 (No) Volume (Both HP MIXER CHANNELS)
amixer set 'HP DAC' 118         # Max Volume    (Both HP MIXER CHANNELS)

Alternate routing to bypass the HP Mixer on both channels

amixer set 'Left DAC Mux'  'DAC_L2'
amixer set 'Right DAC Mux' 'DAC_R2'

Set incoming gain to max
amixer set 'PCM' 127            # Master Play Volume  (Both CHANNELS) 0.5 dB per step

Pink Noise Output:
-t pink means use pink noise (default).
speaker-test -t
speaker-test -t pink
speaker-test -t pink -c 2       # Ctl-C to cancel 

Sinewave tone output:
speaker-test -t sine
speaker-test -t sine -c 2       # Ctl-C to cancel  

aplay -t wav mymusic.wav
Playing internet music with Music Player Daemon

mpd auto-starts as part of bootup

check by typing
~# mpc
volume: 94%   repeat: off   random: off   single: off   consume: off

Music Player Client



mpc playlist    # lists all entries in the current playlist

mpc play        # returns stream or file currently playing
[playing] #1/1   0:00/0:00 (0%)
volume: 94%   repeat: off   random: off   single: off   consume: off

mpc play 2

# wav files do not seem to work, but MP# works fine.
# copy MP3 file to /tmp folder ( because music directory is the /tmp folder )
mpc update
mpc add file.mp3 ( adding /tmp/file.mp3 will NOT work )
mpc play


I found this email in the reflector history useful:

Beaglebone Black Ubuntu playing Music
4 posts by 4 authors  

BeagleBone Capes

Harry May   


since the standard Audio cape is not available, I purchased the DVID-02 cape 
which has HDMI and also the Audio TVL3106 chip which is the same as on the normal 
Audio cape.

I was in anticipation of a nightmare configuring that all (since this cape is 
marked as incompatible with the BBB), I had low expectation of getting it working.

But fortunately this job was done in a few hours and the Audio is working great !

This is how to get it running under Ubuntu:

1) install the BB-BONE-DVID-02 cape, switch on power and login via ssh (no HDMI !)

2) install the ALSA file:
apt-get install alsa-base, alsa-utils

3) check if the TVL3106 can be accessed via I2C interface:
i2cdetect -y -r 1
should show the chip at address 1b  ($18 for Audio Cape 2)

lets test if a write/read access is possible:
write some data: i2cset -y 1 0x1b 2 3
read it back: i2cget -y 1 0x1b 2
this should return: 3

4) lets see if a sound chip is detected:
aplay -l
no sound is detected, thats ok and we will activate it in the next step.

5) prepare the uEnv.txt file
go to the uboot directory and open the file uEnv.txt
(Attention: this file is on the eMMC and also on SD Card, so be sure to open the 
file used for booting !).
add/modify this line:
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G,BB-BONE-DVID capemgr.enable_partno=BB-BONE-AUDI-01

this disables the HDMI (which is required, since the DVID cape is not compatoble 
with HDMI) and also disables the eMMC (since I am only using the SD card for 
Ubuntu, you may do that different)
and (thats the trick): enables the BB-BONE-AUDI-01

Our board is not the BB-BONE-AUDI-01, but since both boards are using the same 
sound chip, we simple use the drivers for the BB-BONE-AUDI-01 board
which works fine with our DVID-02 board.

6) reboot the BBB

7) after rebooting lets check the system log:

this will show that Ubuntu found our DVID-02 board, but the installation failed. 
This is ok, since this board is not compatible with the BBB.

[    2.881593] bone-capemgr bone_capemgr.9: failed to load firmware 'BB-BONE-DVID-02-00A1.dtbo'
[    2.890507] bone-capemgr bone_capemgr.9: loader: failed to load slot-0 BB-BONE-DVID-02:00A1 (prio 0)

But it also shows that the BB-BONE-AUDI-01 was installed successfully and the drivers are loaded:

[    2.900093] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-BONE-AUDI-01-00A0.dtbo
[    2.927274] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'BB-BONE-AUDI-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[    2.976130] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-BONE-AUDI-01-00A0.dtbo' loaded; converting to live tree
[    3.013599] bone-capemgr bone_capemgr.9: slot #7: #5 overlays

8) next lets check the slots file:
ubuntu@arm:~$ cat /sys/devices/bone_capemgr.*/slots
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:PF--- 
 4: ff:P-O-- Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BB-BONE-AUDI-01

as we can see, the HDMI and eMMC are not loaded, but the BONE-AUDI-01 is loaded,
so it should be working.

9) lets test again if a sound chip is found:
ubuntu@arm:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: EVM [DA830 EVM], device 0: AIC3X tlv320aic3x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

yes, it is found.

10) now let us test if its working
connect a speaker/headphone to audio out (speaker only with an amplifier since the volume is very low)
and enter:
speaker-test -t sine

now we can hear a sine wave tone.

11) lets play music
take a WAV file and play it:
aplay -t wav mymusic.wav

Thats it, it was much easier than expected

good luck


You (may) need to add this to your base *.dtb and recompile. You might examine 
the source for the base .dtb you are using to make sure it is there.

(that section can not be loaded as overlay, it must be in your base dtb)



Jan 2, 2018, 3:24:13 PM1/2/18
to BeagleBoard
@Graham thanks for posting this. I expect to have to do some things differently since my target CODEC is different and overlays are now handled differently. In any case, this will give me a good head start and foundation to build on.


Mar 22, 2018, 12:23:31 PM3/22/18
to BeagleBoard
Hey hi Graham,
Its an elaborate and very well explained post. I wanted to use same CODEC to play an audio on BBB but on the latest Debian version 9.3. Device tree overlay structure is very different in the latest images. Will these same commands work on recent images as well? If you have tried it on any recent image,can you please guide?

Stuart Longland

Mar 22, 2018, 9:09:18 PM3/22/18
to beagl...@googlegroups.com
On 22/03/18 19:12, jithu...@gmail.com wrote:
> Its an elaborate and very well explained post. I wanted to use same
> CODEC to play an audio on BBB but on the latest Debian version 9.3.
> Device tree overlay structure is very different in the latest images.
> Will these same commands work on recent images as well? If you have
> tried it on any recent image,can you please guide?

The device tree stuff might change, but I'd imagine everything beyond
"You can check the existence of a soundcard…" should be near identical.

Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.
Reply all
Reply to author
0 new messages