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

    That's really interesting, and your conclusion that it's working more by accident than by design does seem to be reasonable.

     

    Perhaps it  works only because MSB bits change more slowly than LSB ones in normal audio, and therefore although the data setup time isn't being met at the instant of change on any data bit, it's met for several subsequent sample periods on MSB data until the MSB data changes again.  As a result, the failure to meet the setup time is only detectable as LSB noise and so it's too many dB down to be heard by the ear when the audio signal has high dynamic range.  A possible explanation?

     

    For MSB bits, the effect of this 1-sampleperiod delay on each changing bit would mean phase distortion for each frequency component of the waveform of a magnitude proportional to its frequency.  I have absolutely no idea what this would sound like, some kind of timbre colouring I expect.  No idea whether it would be audible either.  Possibly not, since the phase would be delayed by less than 1/100th of a cycle for the standard A above Middle C (A4) pitch of 440Hz which is not a lot, and frequency contributions to an audio signal tend to fall off in amplitude with their frequency so the stronger phase distortion on higher frequency components would tend to be less audible.  Of course, the frequency components are present only in composite form so this is occurring statistically, which makes it very hard to predict the perceivable effect.

     

    Perhaps the effect could be modelled in Csound, but life's too short ...

     

    I wish we could attract Gerald Coley here for occasional comment on BBB design issues.

  • in reply to morgaine

    Thanks!

     

    I checked it out (pasted below). Looks like both ffmpeg and mplayer are pulling in shared libs that look the same for libavcodec, so possibly it is a bug in ffmpeg itself. I've been listening to music on-and-off all day using mplayer, and it's been performing consistently well.

     

    However, I think there is a bug in maybe the driver too, that was not noticeable:

    Basically, in some earlier tests with a logic analyzer I had thought the data was being clocked such that it had to be read on the falling edge of the bitclock. But, I2S requires the opposite. I thought I had made a mistake looking at the traces, but I just checked it again on a scope. The top trace is the bitclock (it is about 3.12MHz, so divided by 64 gives 48kHz sample rate). The bottom trace is the data, and you can see that it changes on the rising edge, so it must be intended to be read on the falling edge.

    image

    Here is the I2S detail from the PCM5101 doc:

    image

    So, the only thing I can conclude is that it is just lucky that the audio is playing, certainly the data set-up time is being violated. Either an inverter is needed, or the driver needs fixing.

     

    image

     

     

    root@beaglebone:~# which mplayer

    /usr/bin/mplayer

    root@beaglebone:~# LD_TRACE_LOADED_OBJECTS=1 /usr/bin/mplayer

            libtinfo.so.5 => /lib/libtinfo.so.5 (0xb6f4f000)

            libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6f29000)

            libz.so.1 => /usr/lib/libz.so.1 (0xb6f0e000)

            libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0xb6ec5000)

            libasound.so.2 => /usr/lib/libasound.so.2 (0xb6e09000)

            libpthread.so.0 => /lib/libpthread.so.0 (0xb6dea000)

            libdvdread.so.4 => /usr/lib/libdvdread.so.4 (0xb6dc8000)

            libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6d50000)

            libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6d1d000)

            libass.so.4 => /usr/lib/libass.so.4 (0xb6cff000)

            libmad.so.0 => /usr/lib/libmad.so.0 (0xb6ce2000)

            libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6cb4000)

            libogg.so.0 => /usr/lib/libogg.so.0 (0xb6ca8000)

            libspeex.so.1 => /usr/lib/libspeex.so.1 (0xb6c8d000)

            libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb6c3f000)

            liba52.so.0 => /usr/lib/liba52.so.0 (0xb6c35000)

            libfaad.so.2 => /usr/lib/libfaad.so.2 (0xb6bf2000)

            libavutil.so.51 => /usr/lib/libavutil.so.51 (0xb6bce000)

            libavcodec.so.53 => /usr/lib/libavcodec.so.53 (0xb6076000)

            libavformat.so.53 => /usr/lib/libavformat.so.53 (0xb5f93000)

            libswscale.so.2 => /usr/lib/libswscale.so.2 (0xb5f61000)

            libpostproc.so.52 => /usr/lib/libpostproc.so.52 (0xb5f42000)

            libm.so.6 => /lib/libm.so.6 (0xb5ed1000)

            libXext.so.6 => /usr/lib/libXext.so.6 (0xb5ebc000)

            libX11.so.6 => /usr/lib/libX11.so.6 (0xb5dba000)

            libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb5cf3000)

            libXss.so.1 => /usr/lib/libXss.so.1 (0xb5ce9000)

            libXv.so.1 => /usr/lib/libXv.so.1 (0xb5cdd000)

            libXxf86dga.so.1 => /usr/lib/libXxf86dga.so.1 (0xb5cd1000)

            libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb5c79000)

            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb5c53000)

            libc.so.6 => /lib/libc.so.6 (0xb5b22000)

            libdl.so.2 => /lib/libdl.so.2 (0xb5b17000)

            librt.so.1 => /lib/librt.so.1 (0xb5b08000)

            /lib/ld-linux.so.3 (0xb6f80000)

            libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb5ae0000)

            libenca.so.0 => /usr/lib/libenca.so.0 (0xb5ab2000)

            libx264.so.129 => /usr/lib/libx264.so.129 (0xb5995000)

            libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb5820000)

            libtheoraenc.so.1 => /usr/lib/libtheoraenc.so.1 (0xb57e7000)

            libtheoradec.so.1 => /usr/lib/libtheoradec.so.1 (0xb57c9000)

            libbz2.so.0 => /usr/lib/libbz2.so.0 (0xb57b8000)

            libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb579a000)

            libXau.so.6 => /usr/lib/libXau.so.6 (0xb578f000)

            libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5783000)

            libts-1.0.so.0 => /usr/lib/libts-1.0.so.0 (0xb5779000)

    root@beaglebone:~# which ffmpeg

    /usr/bin/ffmpeg

    root@beaglebone:~# LD_TRACE_LOADED_OBJECTS=1 /usr/bin/ffmpeg

            libavdevice.so.53 => /usr/lib/libavdevice.so.53 (0xb6edf000)

            libavfilter.so.2 => /usr/lib/libavfilter.so.2 (0xb6eb7000)

            libavformat.so.53 => /usr/lib/libavformat.so.53 (0xb6dd4000)

            libavcodec.so.53 => /usr/lib/libavcodec.so.53 (0xb627c000)

            libpostproc.so.52 => /usr/lib/libpostproc.so.52 (0xb625d000)

            libswscale.so.2 => /usr/lib/libswscale.so.2 (0xb622b000)

            libavutil.so.51 => /usr/lib/libavutil.so.51 (0xb6207000)

            libm.so.6 => /lib/libm.so.6 (0xb6196000)

            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6170000)

            libpthread.so.0 => /lib/libpthread.so.0 (0xb6151000)

            libc.so.6 => /lib/libc.so.6 (0xb6020000)

            libX11.so.6 => /usr/lib/libX11.so.6 (0xb5f1e000)

            libXext.so.6 => /usr/lib/libXext.so.6 (0xb5f09000)

            libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb5efd000)

            libasound.so.2 => /usr/lib/libasound.so.2 (0xb5e41000)

            libbz2.so.0 => /usr/lib/libbz2.so.0 (0xb5e30000)

            libz.so.1 => /usr/lib/libz.so.1 (0xb5e15000)

            libx264.so.129 => /usr/lib/libx264.so.129 (0xb5cf8000)

            libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb5b84000)

            libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb5b56000)

            libtheoraenc.so.1 => /usr/lib/libtheoraenc.so.1 (0xb5b1d000)

            libtheoradec.so.1 => /usr/lib/libtheoradec.so.1 (0xb5aff000)

            /lib/ld-linux.so.3 (0xb6efe000)

            libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb5ae1000)

            libXau.so.6 => /usr/lib/libXau.so.6 (0xb5ad7000)

            libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5acb000)

            libdl.so.2 => /lib/libdl.so.2 (0xb5ac0000)

            librt.so.1 => /lib/librt.so.1 (0xb5ab1000)

            libogg.so.0 => /usr/lib/libogg.so.0 (0xb5aa5000)

    root@beaglebone:~#

     

  • in reply to e14 Contributor

    My ldd script from Gentoo fails on Angstrom most of the time, but the magic incantation that I found in that script

     

    LD_TRACE_LOADED_OBJECTS=1    some_dynamic_executable

     

    works fine on all the ARM dynamic executables that I've put to the test.  The real solution is to get off Angstrom, but a little wrapper script setting the above environment variable will help in the interim.

  • in reply to shabaz

    shabaz wrote:

     

                           

     

    There is no ldd on the BBB Angstrom build :-(

    I'd noticed that a few days ago while trying to work out why starting xterm caused all windows to lose their titles and borders. ldd is just a shell script, so it should be possible to borrow it from some other system. It's tiny as well, so I don't really understand why it's been removed.

     

    But this goes to Jonathan Garrishs post in the "Pi Forums" thread about wanting things to "just work", fine when they do, but when they don't and you find that the tools you use to work out what's going on have all been removed then you've already lost the battle.

  • in reply to e14 Contributor

    Hi Selsinork,

     

    You're spot on, ffmpeg is not built correctly, and a recompile is needed. I've spent the morning listening to some music on the BBB, and there is definitely an issue with ffmpeg, it has what sounds like faint clicks or short interruptions, plus it won't play 24-bit.

    The built-in mplayer doesn't suffer from these issues, and actually sounds superb. I've yet to check if it's truly 24-bit audio by inspecting the I2S stream. There is no ldd on the BBB Angstrom build :-( but I'm guessing mplayer has the libraries built-in rather than shared with whatever ffmpeg is using.