Skip to main content
Topic: I2S DAC board for raspberry pi and beaglebone black (Read 78557 times) previous topic - next topic

I2S DAC board for raspberry pi and beaglebone black

I am starting work on a new project, in principle, today and have started ordering parts to put my plans into action. Its easier to change things on paper than in copper so I thought I would be more transparent in my development process this time, hopefully people will have some thoughts.

The goal is a: high quality, minimum cost, easy, open, networked audio player.

I still like my stereo but the lack of convenience of physically loading discs into a significant. I also obtain digital music sometimes just MP3s sometimes FLAC that does not have physical media to play. High quality audio interfaces exist for PCs and in USB form but don't meet cost/size/power requirements for my living room.

I could put this on hydrogen audio or some audio forum but I think sadly that will result in a lot of FUD. I won't belabor this point but when RF designs are done badly you almost can just look at the board and say yep that person doesn't know what they are doing. Audio is more forgiving and less. To obtain very high performance is hard, to obtain what most people won't hear a difference between is pretty easy.

As some of you might know I had started a project years ago called openHiFi. This was based on a LM3S part and Wolfson DAC. The first prototype worked okay. The software got to a point where I could index a 2.5" hard drive and play any FLAC track on the disc with a serial command. It needed more work though. The digital board produced measurable EM radiation. This was down to it being one of my first PCB designs and a fast number of fast single ended traces on a cheap 2-layer PCB. Fast forward to the present I still have the same desires for a home audio player with an open testable design.

Much of the burden of completing openHiFi was the need for software. When Raspberry Pi came out and then BeagleBone Black, I realized that for non-realtime small volume microcontroller boards like Procyon (on which openHiFi was based) were likely not the best solution. Software ease trumps the slightly reduced cost easily.

With this realization I started to brain storm some options. One of the things I have noticed about consumer hardware is that they do not take audio too seriously. Most cell phones I have had after the cell phone/MP3 convergence sound subjectively worse than the stand alone players that proceeded them. Raspberry Pi is not known for its stellar output from its audio jack. For a long time I2S was not available without a hack. Now it is. I2S is also available on BeagleBone Black (BBB) in principle, though I have to test it, on the black this appears to be fed to the HDMI framing chip. Since those I/Os are sent to the pin header as well it may be possible to simply tap them. I looked extracting audio data from HDMI, while 3rd party boxes do this they generally create SPDIF streams which have worse jitter problems than I2S. Getting access to HDMI directly requires fees I believe.

Jitter may also be an issue with the I2S streams on the Pi and BBB. On the Pi only there is no MCLK output...

Even when I2S exists on a chip as I said jitter on the clocking can make it less than ideal, often times it does not exist, but SPI almost always does.

This consideration led to the formation of an idea of an FPGA based SPI to I2S converter. A CPLD might work as well, but given latencies in the driving I decided buffering would be required to no drop samples. The idea is simple. To minimize phase noise use switch crystals at the true frequency of the stream being output. Support only the common sample rates force resampling of everything else in software. Send the data to several RAM buffers on the FPGA using fast-SPI with a simple 0xFF return for when the buffers are full. This design should practically eliminate jitter, though of course anything produces some jitter and the FPGA is no different, but in principle this may be close to as good as can be done short of an ASIC. At this point I was assuming I would be writing the software as well. I figured I would create a little C program that would handle the streaming to the SPI port in software. Then there would be a need for a software interface to play the files.

At this point I came across http:// and then its successor http:// These projects take a lot of the pain out of the core objective.

The primary author of this project is clearly plugged in to the DIY audio community and he makes some recommendations on USB DACs to use. The most interesting of which is ODAC.


This is an interesting project and as an engineer a breath of fresh air. Objective measurements are always best. Always. You can like whatever coloration of music you want but an objective output + digital processing before rendering should get you any type of sound you want, that's just math. So our goal in producing audio equipment should be objective output with the best possible performance we can manage. The ODAC documentation seems legitimate because it actually tells you very important things like the effective number of bits the board actually is capable of. You can very very easily take a 24-bit DAC and produce 14-bit effective output.

I read every post this guy made about his ODAC design and for the most part it reads well. Apart from jitter on the I2S stream feeding the DAC the other big issue with high resolution DAC stuff is likely going to be the power supply. The creator of the ODAC claims that he has filtered the USB power in a clever way and this let him run it from the USB power. My reply to that is maybe, but the performance of this design is going to be pretty dependent on how good that 5 V power rail actually is.

Thankfully the schematic was published: http:// From this we can see the filtering is not actually that sophisticated. It is just a second order filter and a LDO with a first order output filter. This is the first thing that makes me nervous about taking everything the guy wrote as fact, though I honestly suspect it is. The method however cannot reject high frequency components very well. These are generally above the close loop bandwidth of the LDO and above the self-resonance of the passives. I don't know the later but the former tends to be < 100 KHz depending on the LDO. This may mean these frequencies are not audible but we must remember that any non-linearity will cause mixing and so the high frequencies can be downmixed to audio frequencies. Given the extreme dynamic range specs of audio one must be careful.

The creator of ODAC to his credit spends considerable space discussing the power supply issue, and suggests a worst case remedy of a powered USB hub. This is a fine solution if the powered USB hub's power supply is clean. The other general issue with power is that bad power supplies can create noise on the mains and this can feed into the power supplies of other items. There is no perfect solution. A nice linear transformer though will likely have poor transduction of these high frequencies and the 50/60 Hz and harmonics are not hard to filter.

So if you want an off the shelf solution to me it looks like ODAC + a PCB to let it run off a linear power supply would be a pretty nice one. This would cost over 200 USD though when it was all said and done. Eeep. Given the DAC on ODAC is a 4-8 dollar part this seems excessive.

It also seems a bit silly to have access to an I2S and not use it, instead to use USB transport and then go back to I2S. Its okay in that jitter performance will then be computer independent but it is not ideal in terms of cost. The 200 dollar solution also can be reused. These are good things but it would be nice in my view to have a solution that honestly was affordable and pretty good. Maybe not quite as good as the ODAC but maybe it could be just as good.

There have already been some attempts to make I2S DACs for Pi:

Some look better executed than others but all have things that concern me. The DAC choices seem to be fine. The most common seem to be PCM5102A and ES9023. The later seems more interesting to me because of jitter reduction that may be inside with an asynchronous MCLK (http:// It is hard to tell just from the datasheets what patents it is implementing. The fact that PCM5102A uses a PLL to create MCLK when not presented with a synchronous one makes me think it would not be good at rejecting BCLK jitter. To do so would hurt the stability of the lock in the PLL. It is possible that the loop filter is cleverly designed. But inherently the integration time has to be short enough for it to remain locked or samples will be lost.

Today I made some simple measurements on my raspberry Pi's BCLK output with my  HP 8495E spectrum analyzer. I found the center frequency of BCLK was 1.411251 MHz on a 30 Hz RBW. It is an error of 36 ppm, which is probably just the crystal tolerance. Phase noise is a bit trickier to measure well. A causal estimate with random power supplies is that it is about -54 dBc/Hz at 100 Hz, which is certainly plausible with regular XO clock modules. It is probably better than this though. I'll have to think on how to do a proper measurement of the phase noise.

So to conclude this first post, it I think it would be fun/neat to try to develop a DAC that can be driven by BBB or Pi and uses the Volumio software. It would be nice to measure it objectively as it is developed. I don't own the equipment to do this however.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #1
I have been pondering how I might measure the objective performance of my design this morning and have had some ideas but I want to turn to the power supplies again.

Returning again to the ODAC schematic http:// we can see the critical analog rail is sourced by a MIC5205−3.6YM5. If we read page 1 of the datasheet http://, we can see there is a bi-pass cap used on the LDO to get low noise. On the ODAC schematic no such cap!

This is very odd. If we look at the PSRR plots you can easily see how important this is if you want the LDO to do any rejection. This seems like a rookie mistake and not something I would find on a board sold for 100 dollars even if the designer isn't selling it. That such a cap could hurt performance seems well unlikely. Such oddities can arise in analog design where everything interacts with everything else but honestly it seems unlikely to me. Overall this LDO selection does not impress me. TPS71701 is the best part I have found so far that meets my general requirements but I have only been looking for maybe an hour. At just over 1 USD in small quantities it certainly won't hurt the BOM cost much. My primary gripe with the part is the 6.5 Vmax tolerance, unregulated linear 5V AC adapters might violate it. 9V ones would be not allowed if this part were selected (without an LDO cascade which would help PSRR but hurt voltage noise).

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #2
Tiny update:

First sound. I know it was a long time coming but I had to move and blah blah. I had ordered up some so-so PCBs in December to just check that everything is functional with my concept. So far so good. I've not tried with the BBB yet, though the first iteration I will likely stick to rPi just because it is more widely used.

If anyone knows if the I2S runs on BBB when HDMI is not plugged in (the I2S runs to the framer chip for the HDMI) that would be useful to know.

Most of this project is good PCB layout and power supplies I think (and the case).

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #3
That's good news. I'm working on a similar project, except that I want to connect an audio ADC via I2S.

I did some research on the BBB and it seems to be possible to output I2S when the HDMI is not connected. The processor on the BBB supports multiple I2S inputs and outputs, but as far as I can see the Kernel code only makes use of one of them.

Regarding your post from January, why do you think that cascading LDOs would hurt the noise specs? I'd say that the noise would be dominated by the specs of the last LDO in the chain (ADI AN-1120 seems to confirm that).
The reason why Cbyp is omitted in the ODAC design might be that these LDOs are really sensitive to the value and type of this cap. I used it in a project once and it was oscillating with Cbyp but perfectly stable without it. Also I guess that the PSRR of the DAC is good enough for the noise not to be a problem.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #4
First on the C_byp. The vender clearly specifies the value and it should be used, I've never caused unstable behavior with a properly designed PCB following a manufacturer's suggested value. It will depends on how you load the LDO though of course to some extent.

You are both right and wrong on the last LDO mattering for the noise of the system. The application note is rather long and I know this topic well already so I won't read the whole thing.

If it were an amplifier the noise figure of the first stage would matter the most actually in terms of signal to noise ratio. Here though we have a DC level vs noise at some frequencies. In principle we can reduce all 3 types of noise (Johnson, Shot and 1/f) by reducing the bandwidth of the output of the system to 0 (that is a large ideal capacitor effectively). For this bandwidth reason the last stage could dominate, but it need not. A cascade of two identical LDOs should basically increase the noise by root 2 (for white Johnson noise).

One thing I don't like about the application note linked is the distinction between shot noise and burst or popcorn noise. These are the same physical kinds of processes, based on quantized motion of charges. Their are only 3 types of noise in electronics. The extrinsic stuff mentioned is interference not noise caused by couplings that should be minimized.

Cascading always in general is going to increase noise. Consider a magical world where we have a noise free DC power supply, let's say 9V. I have a regulator that can step down to my needed 3.3 V, but it would get very hot perhaps, so one might be tempted to cascade. If I use one LDO it sees no noise on its input, so all that appears on the output is its intrinsic noise contribution. If I use 2 LDOs in cascade the second sees the intrinsic noise of the first, it will reduce this perhaps within its bandwidth but it is still more than 0, and its intrinsic noise will be added to the output. Although the PSRR increases often with headroom as the AD application note shows cascading is normally better for this figure of merit. You can almost think of the cascade as increasing the open loop gain of the amplifiers that are doing the error detection which should of course help the rejection.

Anyway, let me know if you find neat things with BBB. I was going to just going to see if I could pretend the HDMI was plugged in (if needed) and then have the I2S scooped off the header since it runs to both the header and the framer. Redoing a lot of software stuff in the guts of weird linux distros as fun as hardware for me.

I am still interested in if there is any difference in jitter between BBB and rPi but I think I have concluded I can't measure it well with the test equipment I already own.

In terms of the LDOs I will probably select LT1963/TL1963 and TPS71701. If those are settled I basically just need to select my clock for the ES9023. I suspect the engineers who designed the IC knew more than I have access to when they selected a 27 MHz clock for their asynchronous magic. The patents are pretty undecipherable as patents often are.

I have a means of measuring THD, etc now so I will probably spin my first PCB here soon and get to objectively measuring it in a month or two from now (PCB lead time etc.)

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #5
Another textual update.

I have a prototype and it works. I put pair of standoff holes 180 degrees out of how they should have been but no electrical errors. I tried it out mostly with the Raspberry Pi.

The past couple days I have been trying with the Beaglebone Black (BBB). There are a bunch of good posts about the BBB and I2S here.

One of the more interesting posts about BBB vs raspberry Pi can be found here:

There is a lot of information on using the BBB as an audio player. This person however wants to make a "bit correct" version of the playback. The most interesting thing about the table (to me) are the quotes around "fractional clock dividers". I can only speculate he does not know about fractional PLLs.

Clocking and jitter on the I2S stream can be relevant in that phase noise will increase THD and smear a tone in the spectra of the output. One way to decrease phase noise would be to have a oscillator on board at each sample frequency and then switch them into the Ti processor on the BBB running as a slave. Meanwhile you would feed this same signal to the DAC. Everything would be synchronous to this. To support all frequencies would require many crystals. To lower the number of crystals a high multiple of the 44.1K and 48K series could be used and switched and all other frequencies generated by a counter/divider/integer PLL. This seems to be the approach favored by the author of hifiduino. Phase noise will still exist not only from the oscillator but from all of the inverters etc in the circuit.

Without the external slave driving of the I2S interface the BBB will resample to 48K family frequencies. This is not ideal as the interpolation method is not known. I am not sure if anyone has setup a driver to allow for external driving of this interface in Linux as yet. Given the completely open documentation for the BBB SoC it is not doubt possible.

My initial trial of the BBB has shown less than promising results. As noted in the first blog post series linked to, the bit clock for the data stream is inverted from what it should be in the current kernel. My test board is optoisolated, which makes inverting signals free, so I just fixed it at that point. This bug does show the lack of support for using this interface extensively among developers on the BBB. Most users are using USB DACs rather than the I2S interface.

I quickly turned on I2S by hand and found that for the settings in the Volumio distribution, that there was extreme distortion. I inspected the bit stream with the open logic analyzer to try to find the problem for several hours. The only item I saw were occasional flips of MSBs for just a few samples and then back. Interesting, the MSB was nearly always high. Also some frames seemed synchronized wrong to the L/R clock, but it is hard to say definitively without a more structured wav file than the ones I tried. The distortion was not present when the output was held fractional volume.

Also I must mention Rune Audio. It seems the interface for RaspyFi/Volumio was written by these guys but there was some unspecified disagreement between them and they broke up. Currently the documentation for both Rune and Volumio are lacking but I get the superficial impression that more is going on in the Rune group. Both groups would benefit greatly from opening up more.

Both Rune and Volumio are basically a web configuration interface and MPD client running on top of Linux with MPD. When I tired Rune out there was no baked in support in the web configuration for I2S so I had to configure MPD by hand. Because I had done this I decided just to try to setup a system without the web server part from scratch. I choose Arch because I like their docs and have built Arch systems from the base more often than debian ones where the distro comes more packaged information seems more scattered around.

A few hours later I had a working system, wi-fi, I2S, MPD, Samba, ALSA. So even if these projects go poof or don't improve my little widget will be okay because I can build a system now myself.

This prompted me to wonder if I did the same exact build for BBB (the Arch build was on raspberry Pi) if the distortion/clocking issue would be there. Others haven't reported it but it is possible it isn't my MSB issue but something with clocking and they used 4 wire I2S rather than 3 wire as I am. The truth is that the need for multiple external clocks is disqualifying in terms of complexity for use of the BBB. Therefore if I get back to try this out it will be when I have a lot of time on my hands. As much as I like the greater openness of the SoC docs for the BBB.

I also got through the hard part of writing a script to take FFTs with my Keithley 2015 THD multimeter. I will compare a calculated THD measurement from the FFT data to the internal routine in the meter. I expect them to give the same value. The meter is just sampling the voltage really at high resolution so everything other than that is almost certainly a calculation. If all goes well I should have a nice little python script to do automatic testing of an audio DAC paired with some test wave files for stimulus.

Finally, a compute module was recently announce for Raspberry Pi. I see some positive points to using it but for this application it would increase costs.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #6
Data has arrived. My solution for taking the data was rather crude but I collected data at points 100 Hz apart from 20 Hz to 20 KHz. This was done with the Keithley 2015 as mentioned in the last post.

The results were interesting. The data was taken with a 16-bit FLAC file with a stepped tone sweep. This was synchronized to the data collection script using timers, a crude but effective means of getting the job done.

Data was collected using two implementations of the ESS based DAC, as well as two sources the Raspberry Pi and a Procyon board which was running the openHiFi project I wrote several years ago. Finally I took data with a commercial CD player which had the FLAC file burned to a CD-R.

Here is the result at about 7 KHz:

The worst result is the Procyon + ESS DAC, the best result is the CD player. The two versions iterations of the ESS DAC board are similar. The small shift in the frequency is because one dataset was collected at 7.3 KHz and the others at 7.2 KHz. For the present purposes the noise floor is what demands attention.

This is a bit complicated because on the 2015 to take this data you actually ask it for a distortion measurement of 20 Hz. This gives it the finest FFT it can do (20 Hz per point). It normalizes the spectra to the value at 20 Hz in dB. Since this is in the noise this means the peak value is comparable one acquisition to the next. This problem is remedied by simple normalization of the data based on the peak value. Leveling is easy to check with the RMS AC function which compares correctly to an LeCroy oscilloscope. The CD player output is nominally 1 dB louder than it should be (or the burning software normalized the disc on burning as the reference level was set to -1 dB full scale on the tone track).

This method works well given two different PCB designs yield almost the same spectra using the same source and DAC. There are some limits to the 2015 meter which may cause issues down the line but it has already revealed weakness of the integrated design. Without the objective measurement we might accept this system sounds good but the reality is that it is objectively worse than a rather old shelf CD player! To test to affect of the source of the I2S stream Procyon was used with the same DAC and it was still worse! The most reasonable explanation for the FFTs seen is phase noise/jitter. At least that is what the data looks like. Phase noise on the bit clock would become less of an error as the frequency of the tone is decreased and that is observed. The ESS DAC is suppose to reject jitter and a very lower jitter clock is driving the DAC's MCLK, however no method can completely remove jitter without completely reclocking the data and using a large enough buffer.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #7
My hypothesis from the last post has been verified:

Upon seeing what I felt was obviously phase noise/jitter in the previous data I went out and purchased 2 USB-I2S interfaces that would be compatible with my DAC design. The results are stunning as can be seen above.

I still use the same commercial CD player as a reference for the comparison. This isn't a 2000 dollar CD play or anything but it is a product designed by an audio company who's engineers had plenty of experience. It appears that a USB audio I2S interface plus my DAC is now superior. Someone in my family has a very expensive Rotel CD player it might be interesting to look at the results of.

I believe the displayed average noise level (DANL) on the FFT is now just the limit of the converter in the Keithley meter. There is evidence of non-idealities though, for instance there is a 60 Hz harmonic at only -73 dB. This is unweighted. The more typically reported A-weighting (which has massive flaws apparently as a measurement) would lower this by weighting it -30 dB. For a 1 KHz tone the first harmonic is at -89 dB vs a signal of -1 dB. The rest of the harmonics appear negligible so the THD is about -88 dB. Again this is an unweighted estimate. If you assume a median DANL of -102 dBfs for all 1000 points in the FFT the SNR can only reach -72 dB unweighted. This chip design is likely to be closer to -90 dB therefore I probably need better measurement equipment at this point. Although I can look for the source of the 60 Hz noise still.

One huge take away here though is that: pretty much no solution that uses an unbuffered I2S stream from a Raspberry Pi will be high performing.

I am now looking at the source code of the Kernel driver for the I2S stream, it perhaps could be a software issue but more likely it is the quartz used or the internal jitter of the BCM2835 F-PLL circuits. It does not seem that the makers of crystals specify much in the way of phase noise. For oscillators yes but not for the crystals themselves. The Q of the crystal and its number of 2-level systems clearly would affect phase noise properties. The best performing solution in the plot at the top of this post uses very low phase noise clock. The CD player and other source just probably use pretty good clocks. Clearly the clock on the r-Pi is terrible. Probably if I desolder and replace the crystal with another 19.2 MHz clock the performance will go up at least to the level of the CD player/lower performing USB I2S source. I cannot find out if the BCM2835 will allow a oscillator in place of a crystal on its inputs. Sometimes this is allowed. It is very unfortunate that what is basically the default board for computer on a board/module is from an extraordinarily closed company (whereas BBB is completely open).

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #8
Great information.  I have an rpi connected through i2s to a pcm1794 dac through an isolator/reclocker and it sounds pretty good.  I like it more than my usb->i2s solutions (two different ones).  This is great info to read and learn from, thanks for sharing.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #9
After my disappointment with the Raspberry Pi's phase noise performance I decided to take a second look at the BBB. Firstly because it is a more powerful CPU and is more open if I am forced to use USB audio. Since I first started this worked out what I need to do to build up a ARM Linux system on Arch that runs MPD etc. So I thought I would just try the USB audio enumeration. I can't remember if I played anything with it under USB but ALSA found the low jitter USB interface fine.

I then promptly got distracted with the I2S on the BBB again. I went back and reread the posts I already linked to above. I was very tired and frustrated by the end with the BBB last time and this is partly because I did not read carefully enough. Essentially what is likely is that not building the system from scratch myself I didn't have matched kernel modules last time. This time everything was built up by me from base Arch so I made sure everything was matched.

In short the Botic I2S driver does work fine. The only issue is that you only have an integer clock divider and so it only does 48K family frequencies with the clock on the board. 44.1K family frequencies are sample converted. They are certainly causally lessonable. (Also I haven't checked if the I2S clock is inverted from what it should be as per one of the referenced links before on BBB).

The phase noise of the clock on the BBB is better than Raspberry Pi by far... Again with the same DAC comparing this time the BBB (blue) and the best I2S usb interface:

My next step is to make a clock board to create external clocking for the BBB and see how well that works. USB audio is okay but in the long term it is a more complex and costly solution.


Re: I2S DAC board for raspberry pi and beaglebone black

Reply #10
[quote author="palmito"]Great information.  I have an rpi connected through i2s to a pcm1794 dac through an isolator/reclocker and it sounds pretty good.  I like it more than my usb->i2s solutions (two different ones).  This is great info to read and learn from, thanks for sharing.[/quote]

What chip is it? The thing you are calling the reclocker I mean?

It will be very interesting to see if the BBB + external clocks work well if they do that will end up being the lowest cost open audio solution probably. I don't see any simple way to remove jitter completely without a very large buffer and then things would get laggy. But my ideas are simplistic probably and based on wanting the correct frequency.

I presume we have two clocks both 50 ppm off the correct frequency and the worst case one positive and one negative. So we have 100 ppm or 1e-4. Then 1e-4 samples there will have to be a sample "fixed". That is 10000 samples, or about 4 per second. For regular audio. If supposed that all music is less than 80 minutes per "track" I would need only about 4800*sample size*channels*2 to buffer it. You'd have to wait till the buffer was half full to reclock it. This isn't a huge buffer really just about 16 K I guess but I'm not sure I would know how to detect when I can "catch up" and stop or refill the buffer just from the I2S stream.

Another simple reclocking scheme I thought of doing was well okay I have a terrible clock at some mean frequency and a good one. I use the good one + a PLL and lock to the long term average of the first then I have just the PLL's phase noise + the freq error of the one clock I guess. This is worse than just having a good master clock with an integer divider though. My hope is that the Ti part given it is in slave mode just has a simple CMOS shift register at the output that it keeps full with DMA and thus even if the clocks in the SoC are horrific the output might be okay.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #11
[quote author="brian"][quote author="palmito"]Great information.  I have an rpi connected through i2s to a pcm1794 dac through an isolator/reclocker ...[/quote]
What chip is it? The thing you are calling the reclocker I mean? [/quote]

I'm using an Acko AKL-S03 board ( ... er-gb.html).

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #12
I had a hard time finding anything really giving the detailed chips of the reclocker you are using but the one from Ian and from what I can see on this guy is basically just FPGA/CPLD and shove the XO clocks right out and don't worry about the bit alignment or buffer.

I am not sure how the community over at DIY audio will feel about my design because I'm not going to go for performance at any cost. Just an objectively very good design.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #13
[quote author="brian"]I am not sure how the community over at DIY audio will feel about my design because I'm not going to go for performance at any cost. Just an objectively very good design.[/quote]

I can't speak for the diyaudio community, but I'm interested in what you are doing and the measurements and appreciate you posting your data and designs.

Re: I2S DAC board for raspberry pi and beaglebone black

Reply #14
Thanks man.

After I realized that these two smart bloggers wouldn't be using BBB for audio if it really had the problem I initially encountered and I realized my stupid mistake with the kernel driver, I was much more excited.

I already designed a clock board quickly and sent it to be fabed. I am using NDK clocks which have very low phase noise. I would rather see the frequency space phase noise plot for all clocks but many just give the RMS jitter which just tells you I guess the fit to a Gaussian (it pretty much has to just be the standard deviation). I converted to RMS jitter from the spectral plot of the clocks I am using with the formulas in this app note. It came out about 0.1 ps for nominal clock of 25 MHz.

The idea of reclocking seems fine if people want to go that route, and I did think of a "simple" digital way to reclock with a minimum number of chips. They the BBB uses external clocks though, it shouldn't be needed. The biggest limitation I am going to hit soon is that my test equipment won't measure things this low. I might need to find an ultra low THD/noise source to use as a reference level for further testing. I could build some test equipment to test my designs but then I have a traceability and calibration problem.