Group Actions
Engagement
  • Author Author: shabaz
  • Date Created: Date Created
  • Views 16746 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

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

  • in reply to morgaine

    Yes the PRU can do audio. I wrote a PRU program that accepts audio samples from a .wav file via the host CPU and generates a PCM bitstream on one of the header pins. Just run that bitstream through an RC filter to remove the ultrasonics then to an amp. I'll post the code to github shortly. The PRU program is basically the digital part of a 3-rd order delta-sigma D/A converter. It is really just a toy right now, It can only do mono, stereo requires just a little too much computing (of course you could use two PRUs). A 3-rd order delta-sigma converter is not quite hifi (typical hardware DACs use 5-th order); you can hear some feint artifacts in the very quiet passages.

     

    A possible future project would be to offload some of the computing involved in the delta-sigma algorithm to the host, make it do stereo, and use a higher order algorithm to get rid of the artifacts. However, I'm just going to hook up an external DAC. The PRU program's was really just to get me up to speed on PRU programming.

  • in reply to shabaz

    shabaz wrote:

     

    Regarding the testing, I think this should be possible, there is a serial clocked mode to capture data using a PRU, I've not tried a serial mode yet.

    I wonder if a PRU could itself be turned into an "audio device".  It would seem to have the raw power and realtime behaviour, so in principle it just needs a "virtual audio card" driver on the ARM side to keep the kernel happy and feed it with raw audio, and then dedicate itself to clocking out data at the right rate.  I think I'll head back to your writeup about the ARM-PRU comms driver, as you mentioned that it needs some attention, so it would be a good thing to tackle.  Not just for audio.

     

    For digital audio output, maybe if a CPLD handled wordclock sync then it would relieve the PRU from very tight audio link timing and so it could do a more efficient job of async buffer management to and from the ARM.

     

    I avoid analogue audio  as much as possible.  Life is too short for line noise. image

     

    PS. The JACK ecosystem is kind of the opposite of a "sophisticated application", in the sense that JACK is just a little daemon that acts as a switchboard, and you can't even see it in the image, it has no GUI and doesn't need X11.  (You can kick it off manually or script it, but I use QJackCtl to set up JACK sessions as it has a patchbay to hook things up automatically.)  But while JACK itself is simple conceptually, there are hundreds of programs that hook into the JACK API and run as JACK clients, collaborating any way you like through the connections you configure between them, from colossal Digital Audio Workstations like Ardour to little utilities like Bitmeter, and the whole is larger than the sum of its parts because of the power of combination.  It's pretty good.  And low latency, mine is currently 5.33ms.

  • in reply to morgaine

    Hi Morgaine,

     

    Wow, sounds interesting. It looks like a very sophisticated application. I'll download a copy to try it out on a Linux PC too (I don't have any external soundcard, not sure how expensive digital input/output models are). Getting confirmed 24-bit out of the BBB would be great. I still need to get a PCB made up for a DAC (mine will just have a headphone output, with the PCB being half-BBB width (not a cape) intended just to sit inside near header P8, arranged so the audio socket comes out alongside the USB socket on the BBB - I couldn't see any other compact way of doing this. Or, maybe just bite the bullet and make it into a bigger cape shape, with some generic controls and a small display, but that might be OTT. Not sure : (

     

    Regarding the testing, I think this should be possible, there is a serial clocked mode to capture data using a PRU, I've not tried a serial mode yet. The only slight problem is that it won't be possible to capture a lot using that method because it would fill up the shared mem very quickly (and I've not worked on a driver to extend this), but there is an I2S input that could be used to re-capture the data.. with something other than Angstrom as you say.

    I suppose it could be simulated by converting a WAV file on a PC by stripping off the header, convert into a serial stream and bit-shifting and then adding back the header, and playing it out, to know the effect. But yes, from the findings above, definitely today the bitclock requires an inverter on the PCB if not resolved in the driver, although it seems we're 'getting away' with it due to luck with the timings.

  • in reply to shabaz

    Earlier in the thread we were musing about how to test audio quality, given that the effect of using the wrong clock edge could be slight and  hence difficult to detect by ear.  Well how about the following  approach, entirely in the digital domain ...

     

    Now that the BBB is also a CPLD programmer as per your recent project, you could feed the I2S output into the XC2C64A and capture data on both edges, then feed both captured data streams back into the BBB's GPIO input pins.

     

    The BBB could then compare what it's sending (using raw uncompressed PCM audio) with whatever the CPLD is picking off from I2S.  That should provide a bit-exact confirmation of which edge is right and which is wrong, and if the "good" data is on the "wrong" edge then this will also help diagnose driver or pin inversion issues.

     

    In addition to this, if the BBB is running the JACK audio system then you have many semi-pro to pro tools available to help 1) control what's  actually happening and 2) diagnose problems.  For example, the awesome JACK Bitmeter is an audio techie's delight, and your observation above about no 24-bit data appearing in your I2S output made me fire up Bitmeter to see what was going on at this end.

     

    Sure enough, on my x86 systems at least, mplayer (which uses ffmpeg) generates only 16-bit audio output from the same sound source files (MP3) that my usual player  MOC plays in 24-bit on the same systems!

     

    It's difficult to disentangle the many variables involved when playing music, so I grabbed these useful audio test files that span the usual range of audio bit depths and sample rates in both stereo and mono and alternating stereo, providing a very predictable WAV data set.  It turned out that mplayer isn't pegged to 16-bit on output, but only on decoding the MP3 music, as it'll happily output the WAV files at their respective 8, 16 and 24-bit widths.

     

    This image shows my JACK setup running under QJackCtl, with the top two Bitmeters (L+R) showing 24-bit stereo WAV captured at the moment when only the left channel is carrying sound, while the bottom two show mplayer playing an MP3 which in MOC looks exactly the same as the top Bitmeter.  (In case you're wondering why the two VU Meterbridges don't match the Bitmeters, the screen shot captures the VU state long after that of the Bitmeters -- very unsynchronized.)

     

    image

     

    I don't yet have JACK running on my Debian BBB (and I'm not masochistic enough to try it on Angstrom, which today is even failing in 'opkg update'), but the plan is to set up one of these boards as an audio+MIDI swiss-army knife.  Getting S/PDIF digital audio out of the I2S either on coax or Toslink is part of the plan.