Group Actions
Engagement
  • Author Author: shabaz
  • Date Created: Date Created
  • Views 16725 views
  • Likes 8 likes
  • Comments 126 comments
Related
Recommended

BBB - Building a DAC

shabaz

Introduction

This project was about getting audio out of the BeagleBone Black. The aim was to have stereo audio, at least as good as an iPod. See further below for the circuit, and also a video showing it working.

Later, this project was used to build a PCB design (see below for the link to this part 2, and then the PCB was used to make a home Sonos-type hi-fi audio player (see the link to part 3 below).

 

The BBB has an on-board I2S interface, which makes interfacing an external DAC easy. The I2S interface is connected from the AM3359 processor to the HDMI chip (TDA19988) but it is not required for HDMI to be used in order to make use of the I2S interface. The I2S interface is brought out to some pins on port P9 (see here for details). It was encouraging that Technoshaman and Donald Miller had some success with the interface, so I wanted to try it out and I got some time today.

 

Part 2 to this post, which implements the prototype, can be found by clicking here.

image

Part 3 implements a complete design in an enclosure for a Sonos-like solution.

image

See Creating an Internet Radio for a complete project by the EAGLE team including board layouts

image

 

Parts Selection

Since the interface is capable of 24-bit/192kHz audio, it was worthwhile picking a nice DAC. A good but not over-the-top device seemed to be the Texas Instrument's PCM5101 which is nice because it has reasonable specs and also provides a built-in charge pump so that it can function from a single supply. A headphone amp was connected, and this was ON Semi's NCP2811A. The combination of PCM5101 (actually my prototype used PCM5101A which can also function from 1.8V, but this was not needed)  and NCP2811A was chosen so that the entire circuit could operate from the BBB supply if desired, even if it was from a Li-Ion battery that was powering the BBB, and for low noise and distortion. The only problem is that the PCM5101 has quite a high output (clearly a good thing!) but the audio amp minimum recommended gain is 1 and it cannot meet the required output voltage, and it means that it will distort at high volume. So, at a lower volume (and lower SNR) it will be fine, and I prefer this particular amp because of the very low distortion. The ON semi datasheet was sparse though.

 

Building It

This is the DAC prototype:

image

This is the whole thing connected up:

image

This is the rear of the board - a bit messier! It was built on a SMD to DIP adapter board with some copper tape for supply rails:

image

This is the audio amp - not a lot to it, since it is so integrated.

image

 

Testing It

I made a recording, but excuse the quality. The audio is from a small 64 ohm speaker picked up by a simple camera in-built microphone so it sounds bad, but connecting to headphones is a different story - it sounds as good as an ipod (although this is subjective - I don't have a way to measure). Another thing I still need to check is that originally I thought the data was read on the falling edge of the bitclock on the BBB, but I2S specifies the opposite. Maybe I made a mistake in my initial observations (I have not had a chance to re-check), or maybe it changed in a build. But the circuit as shown here works for me.

 

This is running on an not-recent Angstrom downloaded build (maybe a few weeks old image), and I still hear some very slight audio issues - it sounds like perhaps a break for a few tens of milliseconds occasionally, only if you're listening closely. I really hope it is resolved in a build soon (or maybe it is due to ffmpeg - perhaps avconv gives better results).

EDIT: I've since been using mplayer (command line is mplayer -ao alsa -volume 4 AmyWinehouse-BackToBlack.mp3  and either I'm not noticing any audio issues or they have disappeared). I've concluded it sounds at least as capable as my old ipod touch, maybe better).

 

I played audio using the command line:

ffmpeg -i AmyWinehouse-YouKnowImNoGood.mp3 -f alsa "default:CARD=Black" -re -vol 150

and it reported the stream as:

Stream #0.0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s

 

 

 

Circuit Diagram

This is the circuit. All the 3.3V supplies were connected together for the prototype (I wouldn't do that for real, although it sounded very good in my limited tests). The amplifier V+ can be connected to 3.3V or the 5V supply (or the Li-Ion battery directly).

Note 16th Jan 2014: See the comments section below for more detail; the SCK pin on the PCM5101A was disconnected from 0V and instead connected to the BBB P9 pin 25. This will provide the lowest jitter by disabling the DAC's internal PLL. A sample capture of the audio quality (captured from the headphone output of the NCP2811A, just to give an approximate idea of what it sounds like from headphones) is attached to the post below, in the zip file dac-output.zip. More info on it in the comments section below.

Note 2: Please add a logic inverter to the bitclock connection. For more detail, see the comments below (search for the word 'bitclock' to make it easier to find). See the part 2 blog post, and the attached file there called dac-documentation.zip for the circuit diagram, showing the bitclock inversion. More recent BBB images may not need it, but it was certainly needed for the images I tested with.

image

 

Experiments with FLAC

I've also tried a FLAC file, but I'm hitting some limitation with ffmpeg it seems, and it picks a 16-bit format when it ought to be 24-bit. Meanwhile, avconv I couldn't get to work for MP3 or FLAC (it reported 'av_interleaved_write_frame(): Resource temporarily unavailable'). If anyone knows, any tips on how to play FLAC at 24-bit would be gratefully appreciated.

 

root@beaglebone:~# ffmpeg -i Taxman_2009_Digital_Remaster.flac -f alsa "default:CARD=Black" -re -vol 5
ffmpeg version v0.8.4, Copyright (c) 2000-2012 the Libav developers
  built on May 20 2013 13:00:42 with gcc 4.7.3 20130205 (prerelease)
This program is not developed anymore and is only provided for compatibility. Use avconv instead (see Changelog for the list of incompatible changes).
[flac @ 0x2da80] max_analyze_duration reached
Input #0, flac, from 'Taxman_2009_Digital_Remaster.flac':
  Metadata:
    ORIGREFERENCE   : 6C05C9F79EE74052A7991B9669B98533
    ORIGDATE        : 2009:09:14
    ORIGTIME        : 11:57:01
    TIMEREFERENCE   : 5292000
    CODINGHISTORY   : A=PCM,F=44100,W=24,M=stereo,T=SADiE5
    ORGANIZATION    : EMI
    TITLE           : Taxman
    track           : 1
    ARTIST          : The Beatles
    ALBUM           : Revolver (24 BIT Remastered)
    DATE            : 2009
  Duration: 00:02:37.85, bitrate: 1892 kb/s
    Stream #0.0: Audio: flac, 44100 Hz, 2 channels, s32
Incompatible sample format 's32' for codec 'pcm_s16le', auto-selecting format 's16'
Output #0, alsa, to 'default:CARD=Black':
  Metadata:
    ORIGREFERENCE   : 6C05C9F79EE74052A7991B9669B98533
    ORIGDATE        : 2009:09:14
    ORIGTIME        : 11:57:01
    TIMEREFERENCE   : 5292000
    CODINGHISTORY   : A=PCM,F=44100,W=24,M=stereo,T=SADiE5
    ORGANIZATION    : EMI
    TITLE           : Taxman
    track           : 1
    ARTIST          : The Beatles
    ALBUM           : Revolver (24 BIT Remastered)
    DATE            : 2009
    encoder         : Lavf53.21.0
    Stream #0.0: Audio: pcm_s16le, 44100 Hz, 2 channels, s16, 1411 kb/s
Stream mapping:
  Stream #0.0 -> #0.0

Attachments:
dac-output.zip
  • in reply to shabaz

    I looked through a bit of the driver source last night. It definitely looks like some of the parameters are settable via the DT, but I didn't spend enough time with it to really put any pieces together. The drivers for the EDMA engine, the I2S control of the codec, and the McASP are nicely separated into different files, and then there are some board-specific files that tie them together.  So, it will likely take a bit of time and cross-referencing of the code with the appropriate SoC TRM sections to see whether all the options you're interested in tweaking are tweakable via DT, but it should be possible to create a new board-specific driver file that has all the parameters necessary for whatever hardware configuration you come up with if the ones already there are too different from what you're doing.

  • in reply to e14 Contributor

    Hi Levi,

     

    Thank you for your very valuable comments, and the offer to help. It does seem an incredibly flexible peripheral inside the BBB, which ought to make it perfect for tons of audio applications (I hope someone produces a S/PDIF board too at some stage, so we can have a nice fully open source and open hardware alternative better than Sonos with a bit of software effort. For built-in analog out, apparently it uses the PCM5101 chip too). I was going to try to create a board with optical out, but I didn't get round to it : (

    I have not checked the driver source, but I'm hoping that the code allows for configuration of many of the McASP settings via the device tree, although the device tree isn't really documented anywhere well (that could have changed, I've not checked recently), so requires some experimenting today.

    Still, as you say it sounds like there are lots of exciting opportunities to do what one wants with the BBB's McASP if people are willing to dig into it!

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

  • in reply to e14 Contributor

    Hi Gil,

     

    Sorry for the delayed response. You're correct, pins 6,7,9 from the PCM.. chip will provide you with the audio output. However, notice that there is a 470R and 2n2 capacitor in the diagram in the post above, so you'd ideally you'd want to tap at the junction between the resistor and capacitor (it is a low-pass filter). Once tapped, place a capacitor in line - perhaps 2.2uF or 4.7uF for the left and right channels before you connect to your jack.

    Regarding S/PDIF, you can tap the I2S at the point where it hits the PCM.., but you will need another IC to convert to S/PDIF.  Something like DIT4192 would be suitable.

    I avoid Sonos because of the expense - not convinced it is worth it. You could build your own sonos-like solution with a bit of software effort to make it into what you want: http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2014/03/05/bbb--sonos…

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