I2S Audio on the BBB

[Graham]

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? 

    /sys/devices/platform/bone_capemgr/slots 

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.

Thanks,

--- Graham

==

[ags]

I'm also interested as I have a project where I will interface directly to the I2S/McASP interface. Did you figure it out?

[Graham]

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

==

[ags]

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.

[Graham]

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

==

[ags]

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.

[Graham]

I need to gather it together and do some edits, so it makes sense.

It will be a few days or so.

--- Graham

==

[Graham]

ags:

Here it is.

--- Graham

==

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Making the Audio Cape Work                                          2017 MAY 15

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Notes: 

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:

    dtb=am335x-boneblack-audio.dtb

    cmdline=coherent_pool=1M verbose

    cape_enable=bone_capemgr.enable_partno=BB-BONE-AUDI-02

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

or 

aplay -l  or  aplay -L

================================================================================

Get Robert's asound.state file from

https://github.com/RobertCNelson/boot-scripts/tree/master/device/bone/capes/BBB_Audio_Cape_RevB

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

                

================================================================================

Testing

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

returns:

volume: 94%   repeat: off   random: off   single: off   consume: off

================================================================================

Music Player Client

music_directory

    /var/lib/mpd/music

playlist_directory              

    /var/lib/mpd/playlists

mpc playlist    # lists all entries in the current playlist

mpc add http://kut1.streamguys1.com/kut1

mpc play        # returns stream or file currently playing

returns:

http://kut1.streamguys1.com/kut1

[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   

2/27/14

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:

dmesg

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

Harry

=================================================================================

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.

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-boneblack-audio.dts#L17-L28

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

=================================================================================

[ags]

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

[jithu...@gmail.com]

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?

Thanks,

Jithu.

[Stuart Longland]

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.