BBB - Building a DAC

RE: BBB - Building a DAC

jithu_element14 — Thu, 15 Mar 2018 12:51:42 GMT

Hi Shabaz,

I am trying to play audio file mp3 on BBB using PCM5101A using your circuit only. mplayer is playing mp3 which I can see it on console. but I cant hear any sound from the speaker.

I am attaching my kernel logs

debian@beaglebone:~$ uname -a

Linux beaglebone 4.9.45-ti-r57 #1 SMP PREEMPT Fri Aug 25 22:58:38 UTC 2017 armv7l GN U/Linux

debian@beaglebone:~$ cat /etc/debian_version

9.1

iam also attaching the results of mplayer command:

debian@beaglebone:~$ mplayer -ao alsa -volume 4 ring-8-40047.mp3
MPlayer 1.3.0 (Debian), built with gcc-6.2.1 (C) 2000-2016 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing ring-8-40047.mp3.
libavformat version 57.56.101 (external)
Mismatching header version 57.56.100
Audio only file format detected.
Load subtitles in ./
==========================================================================
Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8000->176400)
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================
[AO_ALSA] alsa-lib: pcm_plug.c:909:(snd_pcm_plug_hw_refine_cchange) Unable to find a n usable client format
[AO_ALSA] alsa-lib: pcm_plug.c:913:(snd_pcm_plug_hw_refine_cchange) Format: S16_LE
AO: [alsa] 32000Hz 2ch s16le (2 bytes per sample)
[AO_ALSA] Unable to find simple control 'PCM',0.
[AO_ALSA] Available elements for device:

[Mixer] No hardware mixing, inserting volume filter.
Video: no video
Starting playback...
A: 29.2 (29.1) of 29.0 (29.0) 9.9%

Exiting... (End of file)

I am not understanding where is the problem. I just enabled spidev1 on my BBB and did the connections 6 pin connections with the dac and connected speaker also. waiting for your response as soon. I am badly stuck.

Thanks in advance,

Jithu

RE: BBB - Building a DAC

shabaz — Wed, 03 Feb 2016 12:06:34 GMT

The EAGLE team has a very nice video tutorial BBB DAC cape and a complete Internet Radio project (including touch-screen interface),

and github repository.

[View:/resized-image/__size/620x225/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-f236cf50-b4c4-44ab-8d57-0f93e7dd3acb/8625.contentimage_5F00_186763.png:620:225]

RE: BBB - Building a DAC

Former Member — Wed, 17 Dec 2014 08:27:18 GMT

FIY: There is initial generic driver implementation for connecting BBB to DAC via I2S/DSD/SPDIF interface with clock switching, multichannel support and other nice stuff.

http://bbb.ieero.com/

It's based on mainline kernel 3.16.1 with some patches added. There is also pre-built SD card image available, so you can try it easily.

RE: BBB - Building a DAC

Former Member — Fri, 12 Dec 2014 06:21:32 GMT

I recently started looking into how to hook a little codec break-out board up to my BBB, and this is a very nice resource. Thanks for sharing your work!

I have worked with an OMAP-based board before, and got to spend a bit of time mucking around with the McASP and similar serial audio cores. The McASP in the BBB is actually an extremely flexible interface, and it supports a whole bunch of TDM-style protocols (of which I2S is one) and also AES3/SPDIF directly! Of course, all this flexibility comes with the price of a pretty impenetrable section of the manual.

Anyway, for I2S alone there are a bunch of options. You can run it with as few as 3 lines; one for the serialized audio data, one for clocking those bits, and one to define the sample boundaries. These two clocks have a fixed relationship to one another that's adjustable to account for different sample widths and sample rates (and when you leave the realm of I2S, different numbers of channels as well). You can also configure the *source* of the clock--it can be provided by either end of the link, and it can be provided directly via the sample clock line, or via a separate high-res timer line that will get divided down to form the sample clock. This takes an extra line, but can clock a whole family of sample rates simultaneously via different clock divisors. In fact, pro audio installs often distribute a high-res and high-quality clock via a separate cable from a special device, so that all the media clocks across all the devices are tightly synchronized and nothing requires sample-rate conversion. Of course, it can also be provided by a media-specific oscillator on the board or even a multi-purpose clock that happens to be a multiple of the required sample rate.

Beyond the basic clock configuration, there's a configurable offset from the word clock edge to determine the bit clock edge at which to sample the data, different bit order and padding options, rising vs. falling edge triggers, etc. Basically, you can talk to just about any chip that does some sort of serialized audio format as long as you're willing to dig into the McASP (and clock configuration/routing registers, perhaps) documentation and the documentation for the other chip. You can probably base your work on an existing kernel audio driver, but it's likely you'll have to get your hands a bit dirty unless you're doing something very close to what's in some current driver.

Hopefully you or some of your other visitors will find this information useful, and I would be happy to answer any questions about the bits of McASP and serial audio protocols I am familiar with.

RE: BBB - Building a DAC

Former Member — Tue, 11 Nov 2014 19:09:43 GMT

Hello all. I am way below the electronics know-how displayed in this thread, but I was hoping one of you could help this electronics novice. I was wondering if you knew that the Sonos Play:1 device uses the same DAC chip from TI (PCM5101A). I have an interest in adding digital and analog audio outputs to the Sonos device. I believe that I can simply tap into pins 6,7, and 9 for the analog output. Would I have to use any resistance or capacitance, or simply solder them to the leads (RCA or 3.5mm plug)? Also, if I wanted a digital output that I could connect to an AV receiver, could i use the I2S (pins 12-16) to tap this, or would I need to build some sort of I2S to S/PDIF circuit? Sorry if my questions are very elementary, please be gentle. I would greatly appreciate you pointing me in the right direction. I have asked this question at Official SONOS owners thread - Page 38 - AVS Forum with no answer. Thanks in advance.

RE: BBB - Building a DAC

Former Member — Tue, 22 Jul 2014 10:36:34 GMT

Hi,

first thanks for these great articles. I would like to know, if you had to modify the devicetree to get I2S working amd if the driver is automatically mounted. Do you know if this works with Debian too?

Best

Tom

RE: BBB - Building a DAC

Former Member — Sat, 08 Feb 2014 00:24:57 GMT

Here's a first draft of my implementation document. It is plain text; I need to HTML-ify it and figure out how to post to github. But I wanted to get the info out there, since you guys seem interested. You can do me a favor by proofreading and critiquing it.

This document explains how to attach an external cs4271 codec to a Beaglebone Black (BBB) and create an audio device that uses the cs4271. Currently I have a working cs4271 on a breadboard connected to the mcasp0 and i2c2 pins header pins. The cs4271 is acting as clock master and can be instructed via ALSA to play or capture audio at 48, 96, and 192 kHz and 16 or 24 bits. There are several quirks that need to be fixed and improvements that need to be made, but there is enough information here to serve as a complete working example of a BBB audio device.

On BBB, an audio device is actually a composite of several hardware devices with some glue code to interface the pieces. Mcasp takes care of framing and clocking, and sending/receiving an I2S audio stream to/from the codec. Mcasp uses the edma engine to do the audio file I/O. What we need to do to create an audio device is to instruct the OS how to communicate with the external codec and instruct mcasp on how to format and control the bitstream and how to configure the codec.

Hardware. The cs4271 sound card is built on a breadboard following the example circuitry shown in the reference document or the codec: http://www.cirrus.com/en/pubs/proDatasheet/CS4271_F1.pdf. This codec has 2 channels of ADC and two channels of DAC. The data interface is I2S and the control interface can be either I2C or SPI. I chose to use I2C in this example. An external crystal can be attached to the cs4271 to generate the master clock. The codec can act as either a clock master or clock slave; I chose to make it a clock master. I expect a locally generated master clock would have less jitter than the mcasp generated master clock. However, clocking from the mcasp ought to work perfectly well.

Physical interface. Jumper wires are attached from the cs4271 to the BBB header for the following signals:

codec BBB mcasp0
lrclk (4) -> fsx (P9.29) and fsr (P9.27)
sclk (5) -> aclkx (P9.31) and aclkr (P9.42)
sdout (6) -> axr2 (P9.28)
sdin (7) <- axr3 (P9.25)

codec BBB I2C2
scl (11) <-> scl (P9.19) (10k ohm pullup may be needed)
sda (12) <-> sca (P9.20) (10k ohm pullup may be needed)

codec BBB GPIO
rst (14) <- gpio0-5 (P9.17)

codec
ad0 (13) <- ground (to set the I2C address)

Note 1. cs4271 mclk out is not connected. The mcasp0 does not need it, apparently getting its internal timing from the codec sclk signal.

Note 2. Without the 10k ohm pullup resistors, the cs4271 did not respond to I2C addresses. It looks like the cs4271 needs a faster rise time on scl and sca than is obtained from the BBB internal pullups. This might not be necessary with other codecs.

If it is desired to make the codec a clock slave instead of master, some changes are needed to the connections. In particular mclk, lrclk, and sclk will be inputs to the codec. There will also be changes to some kernel modules and the device tree overlay for the codec. I have not tried this, but I have noted some things that must be considered in a later section.

Device tree overlay. A device tree overlay needs to be set up that describes the signals, the pin modes, and some device settings. The device tree overlay used in the example is given in appendix A. Note that, since the driver module for the cs4271 (snd-soc-cs4271) is a loadable module, the device tree overlay needs to tell the OS to load the module. This is done by listing the name of the module in the exclusive-use clause of the overlay.

Kernel code changes. A few kernel routines needed to be changed. To do this you will need to rebuild the kernel from source. The best set of instructions that I have found for this purpose are Robert Nelson's, at http://eewiki.net/display/linuxonarm/BeagleBone+Black. It really isn't that hard to build your own kernel. You could even do it on the BBB itself, if you don't mind waiting a a day for the first compilation. However I did it on a fast deskside Linux server, where a full kernel build takes around half an hour. The following kernel files were changed:

Configuration: When you do a build, you are initially offered a menu for changing the kernel configuration. You need to enable building of the asoc codec drivers the first time. Select Device Drivers - Sound card support - Advanced Linux Sound Architectue - ALSA for SoC audio support - Build all ASoC CODEC drivers <M> for modularize. Of course you could just build all the codecs into the kernel, but this wastes space as well as forcing you to rebuild the whole kernel if you want to change something, instead of just rebuilding a single module.

Files to change. Patch files in Appendix B.

KERNEL/sound/soc/codecs/cs4271.c:
fix the codec register addresses

KERNEL/sound/soc/davinci/davinci-evm.c:
change the audio format to LEFT_J, which cs4271 recognizes
fix setting of sysclk and clkdiv
change the codec name to cs4271

KERNEL/sound/soc/davinci/davinci-mcasp.c:
make mcasp a clock slave instead of master
change I2S format to left-justified

Installing the updated kernel on a BBB. Building the kernel generates a directory named "deploy," which contains the new kernel, modules, and device tree files. These have to be copied to the appropriate system locations. I use the following little script (you may have to install rsync):

commands, as root on BBB:
Note 1. change the source directory to your deploy.
Note 2. change the system version if necessary.
Note 3. you should back up the old versions of these.

---
rsync -a /home/jsr/deploy/3.8.13-bone36.zImage /boot
cd /lib/firmware
tar -xzf /home/jsr/deploy/3.8.13-bone36-firmware.tar.gz
cd /
tar -xzf /home/jsr/deploy/3.8.13-bone36-modules.tar.gz
cd /boot/dtbs-3.8.13-bone36
tar -xzf /home/jsr/deploy/3.8.13-bone36-dtbs.tar.gz
---

Using the audio device. You have to disable HDMI because it has some pin conflicts with the audio driver. Reboot into new OS and 'echo jsr-cs4271 >$slots' where slots is your /sys/devices/bone_capemgr.9/slots file. That's it, your are ready to use the new audio device.

'aplay -L' will list the current audio devices
---
jsr@bone:~$ aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=EVM
    DA830 EVM,
    Default Audio Device
sysdefault:CARD=EVM
    DA830 EVM,
    Default Audio Device
dmix:CARD=EVM,DEV=0
    DA830 EVM,
    Direct sample mixing device
dsnoop:CARD=EVM,DEV=0
    DA830 EVM,
    Direct sample snooping device
hw:CARD=EVM,DEV=0
    DA830 EVM,
    Direct hardware device without any conversions
plughw:CARD=EVM,DEV=0
    DA830 EVM,
    Hardware device with all software conversions
---
'
aplay bach.wav' will play a .wav file. Although it might instead complain "Unable to install hw params" if your audio device does not support the rate and bit-width of the source .wav file. In that case you'll need a converter program or plugin to convert the audio to a hardware compatible form. Here's how to make a simple rate converter: In your home directory, create a file '.asound.rc' with the following contents:

---
pcm_slave.sl2 {
    pcm default
    rate 96000
    format S32_LE
}

pcm.rate_convert {
type plug
slave sl2
}
---
Now play your .wav file with the command 'aplay -D rate_convert bach.wav'. Alsa will insert a (crappy) rate converter and sample expander into the audio stream and play your (probably 44.1 kHz, 16 bits) file at 96 kHz, 32 bits format. You can add a -v option to see what the plugin is doing and what the actual hardware parameters are. For example 'aplay -v -D rate_convert bach.wav' produces:

---
Playing WAVE 'bach.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Rate conversion PCM (96000, sformat=S32_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 44100
exact rate   : 44100 (44100/1)
msbits       : 16
buffer_size : 7526
period_size : 470
period_time : 10666
tstamp_mode : NONE
period_step : 1
avail_min    : 470
period_event : 0
start_threshold : 7526
stop_threshold   : 7526
silence_threshold: 0
silence_size : 0
boundary     : 493223936
Slave: Plug PCM: Hardware PCM card 0 'DA830 EVM' device 0 subdevice 0
Its setup is:
stream       : PLAYBACK
access       : MMAP_INTERLEAVED
format       : S32_LE
subformat    : STD
channels     : 2
rate         : 96000
exact rate   : 96000 (96000/1)
msbits       : 32
buffer_size : 16384
period_size : 1024
period_time : 10666
tstamp_mode : NONE
period_step : 1
avail_min    : 1024
period_event : 0
start_threshold : 16384
stop_threshold   : 16384
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
appl_ptr     : 0
hw_ptr       : 0
---

Note. I've heard there is a much better quality rate converter for alsa than the default linear interpolator, but I don't know the details.

Appendix A. Hints for making the mcasp0 be the clock master. TBD.

Appendix B. Patch files for the kernel:

======================================
--- KERNEL/sound/soc/davinci/davinci-evm.c    2014-02-07 16:23:30.800284949 -0500
+++ /home/jsr/linux-dev/KERNEL/sound/soc/davinci/davinci-evm.c    2014-02-05 21:19:04.491499253 -0500
@@ -33,8 +33,9 @@
#include <linux/of_gpio.h>

-#define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \
-        SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF)
+#define AUDIO_FORMAT (SND_SOC_DAIFMT_LEFT_J |            \
+        SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_NB_NF)
+
static int evm_hw_params(struct snd_pcm_substream *substream,
              struct snd_pcm_hw_params *params)
{
@@ -194,8 +195,30 @@
         snd_soc_dapm_add_routes(dapm, audio_map, ARRAY_SIZE(audio_map));
     }

-    /* Divide McASP MCLK by 2 to provide 12MHz to codec */
-    ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 2);
+    /* Divide McASP MCLK by 2 to provide 12.238 MHz to codec bit clock */
+    //ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 2);
+    //if (ret < 0)
+    //    return ret;
+
+    printk(KERN_WARNING "davinci-evm: cs4271 clock init\n");
+
+    ret = snd_soc_dai_set_sysclk(cpu_dai, 0, 0, SND_SOC_CLOCK_OUT);
+    if (ret < 0)
+        return ret;
+
+    ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1); // div by 2 ahclk = 12.288 MHz
+    if (ret < 0)
+        return ret;
+
+    ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, 2); // div by 2 aclk (x 64 bits/frame -> 256 bclk/ahclk)
+    if (ret < 0)
+        return ret;
+
+    ret = snd_soc_dai_set_clkdiv(cpu_dai, 2, 64); // div by 64 (bclk/ahclk)
+    if (ret < 0)
+        return ret;
+
+    ret = snd_soc_dai_set_fmt(cpu_dai, AUDIO_FORMAT);
     if (ret < 0)
         return ret;

@@ -376,10 +399,11 @@
* This struct is just used as place holder. It will be filled with
* data from dt node
*/
+
static struct snd_soc_dai_link evm_dai = {
-    .name        = "TLV320AIC3X",
+    .name        = "CS4271",
     .stream_name    = "AIC3X",
-    .codec_dai_name    = "tlv320aic3x-hifi",
+    .codec_dai_name    = "cs4271-hifi",
};

/* davinci evm audio machine driver */
======================================
======================================
--- KERNEL/sound/soc/davinci/davinci-mcasp.c    2014-02-07 16:23:31.042282778 -0500
+++ /home/jsr/linux-dev/KERNEL/sound/soc/davinci/davinci-mcasp.c    2014-02-05 21:09:57.568357999 -0500
@@ -392,11 +392,11 @@
     * the clock source for another device.
     */
     if((pdir & ACLKR) && (rclk_reg & ACLKRE)) {
-        mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLR_REG, RXCLKRST);
+        mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, RXCLKRST);
     }

     if((pdir & AHCLKR) && (rhclk_reg & AHCLKRE)) {
-        mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLR_REG, RXHCLKRST);
+        mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, RXHCLKRST);
     }

     mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, TXHCLKRST);
@@ -518,6 +518,7 @@
         mcasp_clr_bits(dev->base + DAVINCI_MCASP_TXFMCTL_REG, FSXDUR);
         mcasp_clr_bits(dev->base + DAVINCI_MCASP_RXFMCTL_REG, FSRDUR);
         break;
+    case SND_SOC_DAIFMT_LEFT_J:
     case SND_SOC_DAIFMT_I2S:
         mcasp_set_bits(dev->base + DAVINCI_MCASP_TXFMCTL_REG, FSXDUR);
         mcasp_set_bits(dev->base + DAVINCI_MCASP_RXFMCTL_REG, FSRDUR);

======================================
======================================
--- KERNEL/sound/soc/codecs/cs4271.c    2014-02-07 16:20:47.619748775 -0500
+++ /home/jsr/linux-dev/KERNEL/sound/soc/codecs/cs4271.c    2014-02-05 21:04:05.201931161 -0500
@@ -42,14 +42,14 @@
* High byte represents SPI chip address (0x10) + write command (0)
* Low byte - codec register address
*/
-#define CS4271_MODE1    0x2001    /* Mode Control 1 */
-#define CS4271_DACCTL    0x2002    /* DAC Control */
-#define CS4271_DACVOL    0x2003    /* DAC Volume & Mixing Control */
-#define CS4271_VOLA    0x2004    /* DAC Channel A Volume Control */
-#define CS4271_VOLB    0x2005    /* DAC Channel B Volume Control */
-#define CS4271_ADCCTL    0x2006    /* ADC Control */
-#define CS4271_MODE2    0x2007    /* Mode Control 2 */
-#define CS4271_CHIPID    0x2008    /* Chip ID */
+#define CS4271_MODE1    0x0001    /* Mode Control 1 */
+#define CS4271_DACCTL    0x0002    /* DAC Control */
+#define CS4271_DACVOL    0x0003    /* DAC Volume & Mixing Control */
+#define CS4271_VOLA    0x0004    /* DAC Channel A Volume Control */
+#define CS4271_VOLB    0x0005    /* DAC Channel B Volume Control */
+#define CS4271_ADCCTL    0x0006    /* ADC Control */
+#define CS4271_MODE2    0x0007    /* Mode Control 2 */
+#define CS4271_CHIPID    0x0008    /* Chip ID */

#define CS4271_FIRSTREG    CS4271_MODE1
#define CS4271_LASTREG    CS4271_MODE2
======================================

Appendix C. The device tree overlay.

/*
* Copyright (C) 2014 John Rhoades
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone-black";
    part-number = "jsr-cs4271";
    version = "00A0";

    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */
        "P9.17",        /* cs4271 reset */
        /* i2c2 */
        "P9.19",        /* i2c2: scl */
        "P9.20",        /* i2c2: sca */
        /* mcasp0 */
        "P9.31",    /* mcasp0: aclkx 0x190 */
        "P9.29",    /* mcasp0: fsx    0x194 */
        /* not used "P9.30",        /* mcasp0: axr0   0x198 */
        "P9.28",    /* mcasp0: axr2   0x19c */
        "P9.42",        /* mcasp0: aclkr 0x1a0 */
        "P9.27",        /* mcasp0: fsr    0x1a4 */
        /* not used "P9.41",        /* mcasp0: axr1   0x1a8 */
        "P9.25",    /* mcasp0: axr3   0x1ac */
        /* the hardware IP uses */
        "gpio1_27",
        "snd-soc-cs4271", // needed to get module loaded
        "mcasp0";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            cs4271_i2c2_reset: cs4271_i2c2_reset {
                pinctrl-single,pins = <
                    0x078 0x0f      /* gpio0_5, mode7 */
                >;
            };
            cs4271_i2c2_pins: cs4271_i2c2_pins {
                pinctrl-single,pins = <
                    0x178 0x73    /* I2C2_sda */
                    0x17c 0x73      /* I2C2_scl */
                >;
            };
            mcasp0_pins: mcasp0_pins {
                pinctrl-single,pins = <
                    0x190 0x20      /* P9.31 mcasp0 0->aclkx   */
                    0x194 0x20      /* P9.29 mcasp0 0->fsx     */
                    0x198 0x20      /* P9.30 mcasp0 0->axr0    */
                    0x19c 0x22    /* P9.28 mcasp0 0->ahclkr, 2->axr2 */
                    0x1a0 0x20      /* P9.42 mcasp0 0->aclkr, 2->axr2 */
                    0x1a4 0x20      /* P9.27 mcasp0 0->fsr,    2->axr3 */
                    0x1a8 0x20    /* P9.41 mcasp0 0->axr1    */
                    0x1ac 0x22      /* P9.25 mcasp0 0->ahclkx, 2->axr3 */
                >;
            };
        };
    };

    fragment@2 {
        target = <&i2c2>;
        __overlay__ {

#address-cells = <1>;
#size-cells = <0>;

            cs4271: cs4271@10 {
                   compatible = "ti,cs4271";
                   reg = <0x10>;
                   status = "okay";
            };
        };
    };

    fragment@3 {
        target = <&mcasp0>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&mcasp0_pins>;

status = "okay";

            op-mode = <0>;          /* MCASP_I2S_MODE */
            tdm-slots = <2>;
            num-serializer = <16>;
            serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
                0 0 2 1 /* axr2: capture data, axr3: play data */
                0 0 0 0
                0 0 0 0
                0 0 0 0
            >;
            tx-num-evt = <1>;
            rx-num-evt = <1>;
        };
    };

    fragment@4 {
        target = <&ocp>;
        __overlay__ {
            sound {
                compatible = "ti,da830-evm-audio"; //"ti,am33xx-beaglebone-black";
                ti,model = "DA830 EVM"; // "cs4271";
                ti,audio-codec = <&cs4271>;
                ti,mcasp-controller = <&mcasp0>;
                ti,codec-clock-rate = <24576000>;
                #mcasp_clock_enable = <&gpio2 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */
                ti,audio-routing =
                    "Headphone Jack",       "HPLOUT",
                    "Headphone Jack",       "HPROUT",
                    "LINE1L",               "Line In",
                    "LINE1R",               "Line In";
            };
        };
    };
};

RE: BBB - Building a DAC

Former Member — Mon, 03 Feb 2014 00:20:00 GMT

Success at long last! I now have my cs4271 acting as a clock master and able to interface with the alsa sound system at 48, 96, and 192 kHz. The sound quality is nearly flawless, even with my breadboard layout. The only flaw I hear is a very low level of digital grunginess, so low level that you have to put your ear right against the speaker with the volume fully turned up to hear it. From normal listening distances, it is inaudible. I cannot hear any distortion at all (need to make some measurements). 192 kHz and 96 kHz sound exactly the same to me, but that's not surprising. The input stage of the hifi system to which the analog output of the beaglebone-cs4271 is connected first converts analog to 96 kHz digital. So I have not ever actually heard anything rendered at 192 kHz. There is a slight but obvious, once you train your ears, step up in sound quality going from 48 kHz to 96 kHz. Oddly this can be heard even playing 44.1 kHz tracks ripped from CDs, though it is more obvious on material that was recorded at higher bit rates (I have several 176 kHz tracks obtained from HDTracks.)

Next is to figure out what I actually did in the guts of the sound driver that made it work and why, remove gobs of debug prints, and make a clean patch with just the necessary parts. There are a couple of oddities I don't understand yet. With the mcasp in slave mode, it sends the audio serial bit stream to the DAC on a different pin than when it is in master mode, in fact it sends the serial data on P9.25, which is normally the 24.576 MHz master clock output! I saw nothing in the documentation about this and I never would have guessed it, but I accidentally noticed it on my scope while trying to figure out why nothing was working. Another other oddity is that I'm not sending the master clock frequency from the sound chip to the beagleboard at all. I couldn't figure out where to connect it, given that P9.25 is not an input pin. I suppose mcasp is syncing to the serial clock, which I'm sending on P9.31.

I'm going to make a printed circuit board for the DAC, which hopefully will get rid of the digital grunge. I'll use a different DAC chip, since the cs4271 is quite old and requires more external circuitry than more modern DACs. I started with the cs4271 since there was already a driver for it on the beaglebone. Also I need at least four channels of output and the cs4271 has only two. There are more modern DACs that have up to 8 channels out.

RE: BBB - Building a DAC

Former Member — Tue, 28 Jan 2014 13:43:58 GMT

Hi everybody

I'm in trouble with the beagle bone black audio driver. I've read this discussion. It's very useful and interesting. At the moment I have a lot of questions .I hope you will be kind enough to help me.

My project involves the acquisition of an audio stream from web radio and then forward it to an FPGA by the I2S interface.

I Use this command to provide the audio data

ffmpeg -i http://wma03.fluidstream.net:8080/fluid03 -f alsa "default:CARD=Black" -re -vol 150

With the oscilloscope , I can see clearly the I2S data on the output pins. Of the BBB ( bit clock on 31, L/R on 29, data on 28) . Now the problems begin to rise

1) it seems that for every kind of sound source, the output sample rate is the same : 48KHz. It never changes.Even if i have forced it with normal synytax of ffmpeg ( -ar new sample rate) or with .asoundrc script.

So, is it possible to force an output sample rate of 96kHz? (the initial clock of 24,etc is divided by four ).

I'm going crazy for this [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-f236cf50-b4c4-44ab-8d57-0f93e7dd3acb/contentimage_5F00_2.png:16:16]

2) The audio quality is good enough at 48 kHz ??! I've buy the evaluation board with he same Dac of Shabaz to evaluate the sound.

RE: BBB - Building a DAC

Former Member — Sun, 12 Jan 2014 07:24:51 GMT

Thanks for posting this. I am working on a project to make a high quality digital crossover/speaker and room equalizer. The plan is to use the Beaglebone Black for the DSP, running a 8k or 16k tap FIR digital filter, and a decent multichannel external ADC/DAC, with a channel per driver element in the speakers. My codecs (AKM4621) have been ordered from Digikey, and should show up next week. This article will be a big help getting me started on the hardware aspects. I already have the digital filter software running on a Linux desktop machine connected to a studio quality multichannel box (RME ADI-8 DS). I just finished porting it to the Beaglebone this week, and it can process about 300k stereo samples/sec. That's without any optimization work; I expect I can fine tune it to about twice that speed. Anyhow there's already enough headroom to go for a 192 kHz sample rate. The RME box is limited to 96 kHz.However, that system is kind of old, and it would be nice to have a much smaller stand alone system.

One problem I'm facing is that I cannot really use the Beaglebone-generated MCLK. It just has to much noise and jitter for true hifi and it isn't accurate enough. I need the Beaglebone slaved to an external master clock. That probably means I cannot use the existing I2C interface, I'm assuming it cannot be clocked externally. Of course I'll use the Beaglebone clocks for development purposes, since they're there and working.

RE: BBB - Building a DAC

ukonline2000 — Sun, 22 Sep 2013 09:02:42 GMT

Hi shabaz,

In addition to the necessary hardware, what steps need to configure BBB to use the I2S interface to play audio files?

RE: BBB - Building a DAC

Former Member — Mon, 19 Aug 2013 12:05:40 GMT

I'm not sure if the source code I looked at is the correct driver which is loaded.

However, I browsed through the technical reference manual of the CPU, and the programming model for the I2S and ASP shows there's a bit which defines whether the data should be latched on to a rising edge or a falling edge.

I'll try to configure this bit.

RE: BBB - Building a DAC

Former Member — Tue, 13 Aug 2013 15:18:40 GMT

Hi [mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05],

I'm trying to do almost the same project but with an audio ADC ( pcm4202 ==> http://www.ti.com/lit/ds/symlink/pcm4202.pdf)

Its connecting with McASP port and use I2s interface as well.

If I figure it out, you didnt write any driver or kernel code to get the i2s works on your BBB?

You just connect the pin and use the originally HDMI driver is that correct?

Thanks for your reply, I've been looking a solution for days

RE: BBB - Building a DAC

Former Member — Sun, 07 Jul 2013 11:23:11 GMT

avconv, or more properly 'libav' is just a fork of the original ffmpeg. As can be seen from the startup messages when you 're running the 'ffmpeg' command it's actually avconv/libav that's being used.

I had a look at the whole ffmpeg / libav situation while I was trying to get video streaming running with my RPi Camera. While ultimately, as with any fork, the codebases have diverged to some degree, there seems little to choose between them. However in my case Debian/Raspbian were using libav and had disabled any features they considered to be wrong for them, resulting in something that didn't actually work.

Angstrom similarly has it's own problems, most notably that lots of things have been stripped down to minimums and so may be missing features.

If you're going to do anything media related on debian or angstrom and want either of libav or ffmpeg, I'd strongly suggest building these and any dependencies yourself from source and ignoring the distro versions as that will allow you to choose the features you need. It may also be worth trying your file with both libav and the original ffmpeg as it's always possible there's a bug in one that's been fixed in the other

Maybe also try some different players like http://flac-tools.sourceforge.net/ http://alsaplayer.sourceforge.net/ MPlayer, VLC, Xine etc.. I'm assuming most of those probably aren't available for angstrom, so some compiling may be required [View:/resized-image/__size/16x16/__key/commentfiles/f7d226abd59f475c9d224a79e3f0ec07-f236cf50-b4c4-44ab-8d57-0f93e7dd3acb/contentimage_5F00_1.png:16:16]