Dangerous Prototypes

In development => Project development, ideas, and suggestions => Topic started by: brian on January 03, 2014, 10:32:48 am

Title: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on January 03, 2014, 10:32:48 am
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://http://www.raspyfi.com/ and then its successor http://http://volumio.org/. 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.

http://http://nwavguy.blogspot.com/2012/04/odac-released.html

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://http://www.yoyodyneconsulting.ca/downloads/General/ODAC/ODAC-release.pdf. 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:
http://http://www.tjaekel.com/T-DAC/overview.html
http://http://www.hifiberry.com/
http://http://www.raspyfi.com/forum/everything-else/i2s-raspberry-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://http://www.esstech.com/pdf/about-jitter.pdf). 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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on January 03, 2014, 10:28:01 pm
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://http://www.yoyodyneconsulting.ca/downloads/General/ODAC/ODAC-release.pdf we can see the critical analog rail is sourced by a MIC5205−3.6YM5. If we read page 1 of the datasheet http://http://www.micrel.com/_PDF/mic5205.pdf, 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).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on March 13, 2014, 07:36:18 am
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).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: ferdinandk on March 13, 2014, 01:12:58 pm
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 (http://http://www.analog.com/static/imported-files/application_notes/AN-1120.pdf) 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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on March 13, 2014, 05:16:03 pm
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.)
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on April 13, 2014, 06:08:09 am
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 (http://http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/07/06/bbb--building-a-dac).

One of the more interesting posts about BBB vs raspberry Pi can be found here:
http://http://hifiduino.wordpress.com/2014/03/10/beaglebone-black-for-audio/

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 (http://http://ti.com/lit/an/swra029/swra029.pdf).

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 (http://http://www.runeaudio.com/). 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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on April 27, 2014, 09:40:03 pm
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:

(http://http://teholabs.com/docs/_media/openhifi2:pro-rpi2ways-cd.png)

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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 11, 2014, 01:45:46 am
My hypothesis from the last post has been verified:

(http://http://teholabs.com/docs/_media/openhifi2:i2ssources.png)

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).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: palmito on May 12, 2014, 03:17:27 am
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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 12, 2014, 07:15:01 am
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 (http://http://bbb.ieero.com/) 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:

(http://http://teholabs.com/docs/_media/openhifi2:bbbvsusb.png)

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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 13, 2014, 01:26:47 am
[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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: palmito on May 13, 2014, 11:56:54 pm
[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 (http://www.diyaudio.com/forums/group-bu ... er-gb.html (http://www.diyaudio.com/forums/group-buys/227502-amanero-isolator-reclocker-gb.html)).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 14, 2014, 02:34:39 am
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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: palmito on May 14, 2014, 03:25:07 am
[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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 14, 2014, 06:13:38 am
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 (http://http://www.maximintegrated.com/app-notes/index.mvp/id/3359). 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.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 27, 2014, 03:30:33 am
This weekend I got PCBs back for an external clocks board. I used some of the best clocks that I know of in terms of phase noise close in, far beyond what I have observed thinking that would perhaps kill off the phase noise problem. After all the output of the BBB is some dumb FIFO that is driven as a slave from the MCLK. It should just be a set of CMOS dividers that create BCLK and LRCLK and the data well that's just a shift register with some parallel load behind it no doubt.

The results were a bit of a disappointment: basically no change. But why? And so my investigation continues...

At first I believed that somehow the SoC that is the core of the BBB must be contaminating the clocks, after all the most reasonable way of thinking about the "phase noise" observed is clock jitter. So I decided to try to make my own clocks and throw out the BBB signals except for data. To do this I wrote a tiny bit of VHDL and used a CPLD board with a 9 bit counter on it. The result is a bit surprising given the wiring mess this created:

(http://http://teholabs.com/docs/_media/openhifi2:cpldvsbbb.png)

If that isn't no change I don't know what else could be, but given what I believe the output of the SoC is I just traded basically the same circuits in CMOS for a new location in doing this.

I looked a long time at power supplies as well. Ripple on the power supplies could cause the threshold to move around a bit and cause some jitter though I bet if I formally calculated it it would be not enough to worry about (unless the power supply was much worse than it is). This didn't show up anything either. I only went down this track because my best result was made using a floating USB powered port on a laptop.

Which brings me to my next test. I had done the USB I2S interface test under windows just because my GPIB scripts are under windows with python XY. I have been running all the BBB and rPi testing for some time now using Arch and I have an Arch Linux laptop. I had already seen that the result of trying to use the best USB audio interface connected to the BBB was horrific but I was a bit concerned about if the power was enough to really keep everything stable. As a result I thought it would be very wise to check the best USB I2S interface under Arch on a powerful x86 laptop:

(http://http://teholabs.com/docs/_media/openhifi2:laptop.png)

It is a starling result. The upper curve (blue) is from playing a FLAC file encoded 44.1 K 16-bits of the tone using ffmpeg:
ffmpeg -i test41K7p2.flac -f alsa "default:CARD=Audio" -re

for the lower curve I simply decoded the FLAC file first (http://teholabs.com/test41K7p2.flac (http://teholabs.com/test41K7p2.flac)) to a wave file using ffmpeg then played it with aplay:
aplay -Dsysdefault:CARD=Audio test41K7p2.wav

This is a pretty amazing result in some ways, I would assume the ffmpeg statement is just a pipe like construct to the same ALSA interface as aplay uses. Someone with more knowledge of Linux audio could set the record straight. This result however is the first hint that the software is mattering a lot.

While this USB interface certainly supports 48 and 44.1 K families, I didn't check if Linux was aware of this. Playing 48K files seemed to work better on the BBB. I should check exactly how it is registered but it is a low priority as the much bigger result was how important the software stack was in the results. Once I saw the per-decode difference + aplay, I had to try it on the BBB.

(http://http://teholabs.com/docs/_media/openhifi2:bbbaplaytests.png)

Using only aplay and the same file as before, I got the terrible upper curve. Then I tried a 48K file and I got the middle curve. Now note it isn't as good as the near delta function like result on the laptop! As I said I presume it is resampling (badly) the 44.1K file for this interface. The best curve is the old I2S interface on the BBB for comparison. It is a bit better.

These results are interesting. To me they point at software as being the issue rather than hardware. So my hypothesis now would be that the "phase noise" seen in all my plots up to now might be mostly software related. Even the Raspberry Pi stuff could just be the software. The indirect evidence for this is the similarity of very different DAC/PCB layouts in terms of the resulting spectra, and the huge differences with only simple changes in how Linux is supplying the hardware with data seen in the laptop data.

Unfortunately, I know far more physics and pure EE things than I do Linux software things. The evidence certainly points to the software stack probably missing samples in the stream. The only way I can think to check that at this time is to use a logic analyzer to inspect and decode the data stream, but given the spectra the corruption if that is what it is, is not that frequent. I could look at the USB case perhaps as that would be much more frequent but I care more about the onboard I2S case.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jrling on June 22, 2014, 12:06:22 pm
Hi - fascinating read and most impressively presented but also particularly your thought processes based on sound physics.

I was initially greatly attracted to your proposal of a FPGA as the driver for the I2S stream, but gradually this seemed to morph into a Rpi or BBB project. Both SoC to me seem inferior to a hand-rolled FPGA based project by someone like you who knows how to do it properly.

Then using MPD/ALSA/Linux surely is going to 'spoil the party' before you have got any data into your domain. My experience of that replay software even with good PSU/mobo etc. is poor. Even Windows-based audio playback can be much better (MQn for instance aces MPD). Ditto the software on the BBB seems suspect, as you say.

I am an Accountant not an audio engineer, so may be missing many points!

My dream is a player not based on any mainstream OS which cannot be the right choice of OS for audio. Not using USB which has its own issues. A dedicated FPGA hardware and software platform for audiophile playback. Sounds easy, but of course is not.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 22, 2014, 08:26:35 pm
Thanks for the comment. The project hasn't really slipped into using BBB or r-Pi they are in the title...

I think having an FPGA or CPLD "sound card" certain is viable but really doing the whole decode of all the formats on an FPGA is probably a waste of effort. One could fairly easily write a blob of software in Linux that sent PCM data to a large buffered output over say a SPI port along with the clocking information (IE the header). In most cases SPI easily gets to 20 Mbit even on just microcontrollers. Meanwhile redbook audio is only 44100*2*16/1e6 -> 1.4 Mbit. Even 192/32bit is only 12 Mbit in stereo. We aren't talking about a ton of data here. The big problem with this approach is really the software.

Apple reminded the world that user experience counts. That really is the sticking point. I may actually be past the point where I can hear the difference myself, after all the distortion of speakers and headphones is far more than the early part of the data stream. However, someone can still hear the differences I am observing objectively.

I don't believe the SoCs are inherently jittery, particularly BBB when it is operating as a slave (it doesn't make sense that it would have a lot of jitter anyway). I think the CPLD experiment excluding the possibility that it was just the clocks that were jittering pretty well. I have also shown that, while software dependent, a linux computer using aplay gave essentially the same spectra as a windows one using the same hardware. So it likely is down to the software. As modern 1 GHz arm processor that only uses 4% of its power for decoding the file should be more than capable of delivering all the samples correctly which seems the issue. Making it so is harder than it should be though.

Also I have been thinking of using a CLPD just to test the DAC quality in the most controlled manner I can and was examining the data in a wave file at 11025 Hz where I would only need 4 samples to do a sine wave... Turns out the floating point truncation doesn't yield exactly 1, 0, -1, 0. Two pieces of software have this "issue" I don't know if the dittering is intentional or not but it will look like phase noise if you just think of the FFT of the result, and assume the DAC's rendering is perfect. This isn't the cause of my observation though as everything is using the same wave file basically.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jrling on June 22, 2014, 11:12:04 pm
Interesting and thanks.

Quote
I have also shown that, while software dependent, a linux computer using aplay gave essentially the same spectra as a windows one using the same hardware. So it likely is down to the software. As modern 1 GHz arm processor that only uses 4% of its power for decoding the file should be more than capable of delivering all the samples correctly which seems the issue. Making it so is harder than it should be though.
I have been testing MQn player software for over a year. It runs on Windows using WASAPI output. The author has worked really hard at optimising the render loop. Users have gone to great lengths to 'optimise' the Windows platform to minimise unnecessary processes etc - myself included. The result has been amazingly good with 16/44.1 WAV/FLAC files - far more detail and fidelity that one could have ever imagined. The astonishing thing is that changing just one instruction in the render loop can make such a difference to SQ. Not subtle at all.

So far noone has been able to put an empirical explanation forward to explain why this is so marked or at all. I run a Chord DAC which has a 4 second RAM buffer reclocking the S/PDIF stream and feeding it directly to a FPGA (Xilinx) based DAC. Even with that DAC the same differences are noted so it is unlikely to be plain jitter errors.

MPD running on an optimised PC was poor quality for me, even just plain pass through with no mixing/upsampling. I conclude that it was MPD causing the poor quality, as a minimised Linux OS should be far less intrusive than 'The Bastard Windows'.

No doubt you have been following the BBB Botic cape project by Russ of Twisted Pear - http://http://www.diyaudio.com/forums/twisted-pear/250583-building-open-embedded-audio-applicance-80.html. It is nearing completion and will be very interesting to hear it and whether they have got over the software issues using a BBB.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 23, 2014, 03:42:06 am
Yes I know of it. I designed the cape they needed in just a couple hours. Twisted pair audio doesn't make objective measurements of any of their designs as far as I know. If you like what they sound like then okay, but I don't have any particular interest in their project unless they are going to measure the result objectively. If I could get access to a better audio analyzer I could optimize my design more. At this point my plan is to reduce the harmonics I can see with what I have and presume the noise floor is limited by the dynamic range of my measurement device (this is a reasonable assumption), therefore I can calculate and approximate THD+N number by measuring the noise floor as a function of volume and fitting the data then add back in the harmonic content at a standard reference level. Without 5-20 K of equipment that is the best I can hope for. I believe I am basically at 0.004% THD+N right now. I haven't calculated the DNR yet, as I had to look up how that is defined by audio measures yesterday but made a measurement today to give me an idea of where I am. Then I just have to take a 2 tone spectra. I am considering switching to a Ti part now that I basically have decided not to use the r-Pi for this project and thus will have a MCLK. I can really use any DAC but I agree with the ODAC creator that a built in negative charge pump supply and voltage mode output is far easier to design with than IV stages. Audiophiles can decide what coloration they want on their music and all that, but the objective quality is the only real thing that matters if you want to color your music from the source just equalize it before it reaches the DAC in digital space.

As far as your comments on Windows software stacks, I don't know them in detail. MPD just calls ALSA if you set it up that way and FFMPEG (in my case) as the decoder. ALSA down to the I2S is all I worry about the rest of the stuff can easily be fixed.

Twisted pair audio's cape will have all of the same problems as my design in terms of performance as I have clearly shown it has nothing to do with my board's layout. If they solve the software issues great, I use the same driver for my clock board. I may release a clock board for BBB myself which I would guess would cost fraction of what Twisted Pair would ask.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on June 23, 2014, 09:14:03 am
Hi Brian,

How do you power your BBB in these measurements? Have you tried a good linear supply?

I'll provide new Botic driver driver and SD card image in the next few days. In its kernel the PMIC of BBB will programmed to fixed frequency clock, so there will be less EMI generated by BBB itself.

Thanks for measurement. Also I'd welcome if there would be more clear descriptions what is measured.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jrling on June 23, 2014, 08:26:24 pm
Hi Brian - your approach is exactly what I would do if I was an audio designer, which I am not. Objective management is really what it is all about at the end of the day, and IMHO virtually none of the commercial vendors base their designs on. And it shows in the end result.

If you need any testers when you get a bit further down the road, I would be very keen to help. I have what I think is a good base to measure (by ear) against MQn player, where there is a critical audience for that designer's output.

I don't know if you were thinking commercially (I am an Accountant in London), but I reckon there is a small but steadily increasing number of audiophiles who would pay for a superior end result in a DIY or near DIY market if a competitive price could be achieved. Certainly, the TP embedded BBB project is getting a lot of support at the design stage.

I will follow the project with interest.

Cheers
Jonathan
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 24, 2014, 02:16:03 am
[quote author="miero"]Hi Brian,

How do you power your BBB in these measurements? Have you tried a good linear supply?

I'll provide new Botic driver driver and SD card image in the next few days. In its kernel the PMIC of BBB will programmed to fixed frequency clock, so there will be less EMI generated by BBB itself.

Thanks for measurement. Also I'd welcome if there would be more clear descriptions what is measured.[/quote]

First of all thank you so much for writing the driver for BBB to begin with Miero. I read all the code and was starting to try to think about how it all worked but I think I would need to spend a few more days at minimum to understand the ALSA audio subsystem before I could fully understand all those data structures.

As for how the BBB was powered. I had tried both normal linear power supplies (transformers + rectifier + cap) and some of my Agilent bench supplies. The I2S interface was fully isolated and the DAC was powered using a separate linear power supply that was kept constant across all the tests. The CCMR should be quite good on the digital side given how it was isolated. I know basically that some part of the I2S stream is at fault for the extra jitter. That's 99.9% certain.

I think strongly that the data stream itself is what is wrong. The thing that points is the CPLD experiment where I generated all the clocks using dividers (and got the same spectra) and the software stack changes making a difference.  If you are interested I used NZ2520SD clocks for the 2 clock sources obtained from DIYINHK. The clock PCB is minimal with just minimum length traces to the clock input pins and NPO 0603 decoupling capacitors.

I agree with you also if you have a good calibrated sound card you can do better measurements than what I can do with the Keithley THD meter, however the calibration is the tricky part if you do it that way.

If the only thing you are going to change is the power management I am not sure that will do much for what I have observed. I honestly believe it is dropping samples occasionally. Do you know how to set the PID priorities of everything from ALSA to the I2S kernel driver that you wrote to a higher level? It doesn't seem like with low utilization it should drop anything but that seems the most reasonable explanation at this time. I am running the OS off an SD card if that latency matters... I did notice the IRQs for all the different flash devices when I was trying to figure this issue out by myself.

Finally I haven't read the datasheet of the power management IC but spread spectrum frequency would generally be lower than fixed for EMI, but you probably know all about that stuff... I don't really know what you are working on just thought I should mention the obvious.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 24, 2014, 02:21:58 am
[quote author="jrling"]Hi Brian - your approach is exactly what I would do if I was an audio designer, which I am not. Objective management is really what it is all about at the end of the day, and IMHO virtually none of the commercial vendors base their designs on. And it shows in the end result.

If you need any testers when you get a bit further down the road, I would be very keen to help. I have what I think is a good base to measure (by ear) against MQn player, where there is a critical audience for that designer's output.

I don't know if you were thinking commercially (I am an Accountant in London), but I reckon there is a small but steadily increasing number of audiophiles who would pay for a superior end result in a DIY or near DIY market if a competitive price could be achieved. Certainly, the TP embedded BBB project is getting a lot of support at the design stage.

I will follow the project with interest.

Cheers
Jonathan[/quote]

The project is first and foremost for myself and my family and friends who love music. However, if it meets a level I can really be proud of I will probably make it available at that time to the public with pretty full transparency of where the costs and overheads are for any production of it are. I had a company which lost money and I better understand the value of my time and the risk of having left over stock. I will at minimum release all the Gerbers and parts lists when I am satisfied I have done a good job. It already is better than my CD player I have listened to music on for 15 years. It is close to the spec of my NAD amplifier as well, once it passes that point I basically don't have anything I gain out of improving it more.

Thanks for your offer and I will keep posting here as I have time to work on it.

This has been a very fun project for me because of all the efforts of all the free software folks and I certainly want to give hardware which I am at least okay at designing back to the software community.

Brian
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 24, 2014, 02:49:13 am
I missed the last line of your comment miero. More clear description of what was measured.

In almost all cases a single tone spectra at -1 dBFS was measured at 100 Hz spacing from 20 Hz to 20K and stored. The spectra were taken using a Keithley 2015 THD meter. The bin size was 20 Hz in the FFT and all numbers are just calculated off the FFT. No weighting is applied to the FFT. The low frequency noise is interesting but maybe from other things in the room.

The single tone was generated by the tone generation function in a wave editor at 32 bit resolution then reduced to 24 or 16 bit resolution file for playback. Inspection in a hex editor of the file does show rounding errors or dithering harmonics of the sample frequency (IE 11025 does not only contain 4 binary values for a 44.1 KHz file). This issue would also appear in the USB I2S stream measurement so it is not the main source of the phase noise.

The dynamic range of the 2015 limits the noise floor in the FFT for -1 dBFS. If we assume the noise other than harmonics is fixed then the SNR will remain fixed until the true noise floor is reached. I should be able to estimate the DNR and real THD+N with this assumption. Most DACs THD scale in this way (see the pcm5102a datasheet).

Comparisons to CD players were made by running them stock and playing a CD burned with the WAV file with stepped tones in it. All other comparisons were made simply by swapping the source of the I2S stream.

Originally MPD was used as the audio program decoding the file for playback (via FFMPEG). I player switched to using a bare Arch distribution with playback of wav files through aplay only. Decoding files was done before hand using FFMPEG, followed by playback of the wave file. Commands were issued via SSH. For the BBB connection was made via Ethernet. For R-Pi by WiFi dongle. The computers were powered by linear power supplies in some testing cases to try to make sure power quality was adequate to suppress jitter.

If this isn't enough information about how testing was done please ask a specific question and I will try to answer it in a more clear way.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on June 24, 2014, 11:48:25 am
Quote
The I2S interface was fully isolated...
How did you isolate I2S? Couldn't the isolator worsen the performance?

Quote
The thing that points is the CPLD experiment where I generated all the clocks using dividers (and got the same spectra) and the software stack changes making a difference.
This is what I don't understand. Did you generate bitclock & lr-clock via CPLD and then feed it into BBB? This can be done, but the McASP controller must be properly configured. But this was not part of my driver.

Can you guess what will be a jitter intruduced by CPLD? Do you expect it will be smaller than internal dividers in the BBB?

How long I2S cables are you using? The lot of noise can be catched on long cables.

Quote
... spread spectrum frequency would generally be lower than fixed for EMI, but you probably know all about that stuff...
I've not verified that, but BBB manual states about step-down converter: "For low-noise applications the devices can be forced into fixed frequency PWM using the I2C interface."

Quote
I honestly believe it is dropping samples occasionally.
BBB and Botic driver, right? Does this also happen with 44k1Hz or 48kHz stereo streams?

If you use aplay it reports underruns, when there is not enough data to be sent to kernel. If underruns are reported then there is slow media, slow CPU for resampling/decoding or insufficient buffers sizes.

The problem could also happen in the kernel if samples are dropped without any report by aplay. For example when CPU is busy handling other interrupts (net, mmc, usb...), or when audio data rate is too high for the BBB.

The fastest file access seems be when remote storage is mounted via NFS. Then cifs (windows shares) but I had to set cache=none option to fix underruns with aplay.

Nevertheless I'm having similar issues when debugging driver 4 channels at 192kHz rate. Two channels "sound" ok, other two do not. But I'm trying to find a way at least to detect if sample was lost in the kernel...
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jrling on June 24, 2014, 03:34:26 pm
Good luck!

Quote
My dream is a player not based on any mainstream OS which cannot be the right choice of OS for audio. Not using USB which has its own issues. A dedicated FPGA hardware and software platform for audiophile playback. Sounds easy, but of course is not.

I think your last post rather demonstrates my point about OS. Linux is an OS that is aimed at much bigger applications than just rendering PCM to a DAC. Better (less bloated) than Windows, but nevertheless has loads of threads running all competing for time of the CPU and RAM and then also slap bang in the middle of a PC/laptop environment full of RFI/EMI.  Hardly ideal however good the writer of the audio software is (Miero is very good I am sure).

A dedicated simple hardware platform like a FPGA doesn't need an OS as such. All it does is turn on and do the only thing it knows how to do all the time and timed perfectly. It does not need to be high power and very quick, because it is only doing one relatively undemanding task. The sort of platform I am referring to is well described here - http://http://ultra-embedded.com/fpga_audio although his aim was not to give top priority to audiophile performance, so I am sure could be improved upon. PSU with such a low power device ideally could be Li-ion battery with very good low noise performance.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 24, 2014, 04:08:35 pm
Jrling:

You are basically arguing for a real time system over a preemptive one. Yes it can be an issue in principle. But the data rate is slow slow for audio that keeping a FIFO for it full should be trivial even with a polled querying of the FIFO's status on preemptive OS. If there are no buffer underruns and the output circuit from the FIFO to the I2S pins are identical then there would be no difference between an SoC solution running a preemptive OS and a real time system on something like a micro controller or an FPGA.

Now please note I am saying the I2S circuitry is the same in this thought experiment. That's everything: the clocking, and PLLs the serializer all that stuff. That stuff is implementation dependent. At these low data rates digital stuff is actually pretty easy to get right.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jrling on June 24, 2014, 04:31:28 pm
I do of course defer to you much greater knowledge in these matters.

But I have tried several Linux-based dedicated audio(phile) players (e.g.Squeezelite, Daphile, MPDpup) the latter two running on really cut down Linux OS and the results were not that good. I get better by a long way with MQn on Windows with exactly the same PC and replay chain.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 24, 2014, 04:35:58 pm
[quote author="miero"]How did you isolate I2S? Couldn't the isolator worsen the performance?[/quote]

In the general case isolation could hurt performance. In this case it was a variable that was controlled for.

There are two blobs: an isolated DAC + cables and an I2S source. the I2S source is changed, everything else is fixed. Therefore any difference observed is in the I2S source. I observe that the USB I2S source has much lower phase noise in the FFTs I took. Therefore the BBB and r-Pi I2S streams have attributes that increase the phase noise.


[quote author="miero"]This is what I don't understand. Did you generate bitclock & lr-clock via CPLD and then feed it into BBB? This can be done, but the McASP controller must be properly configured. But this was not part of my driver.

Can you guess what will be a jitter intruduced by CPLD? Do you expect it will be smaller than internal dividers in the BBB?

How long I2S cables are you using? The lot of noise can be catched on long cables.[/quote]

I already addressed the cables in the previous remark, since they are fixed they should not be the cause (assuming the LVCMOS drivers are equally able across all of the I2S sources used).

My thought when I observed the worse phase noise from the BBB was that one of the clocks must be bad. To test this hypothesis I wrote a code that replaced all of the clocks from the BBB I2S stream with ones generated from a CPLD. I did not feel this would necessarily be better, but that it could be and it should be different in all probability.

The LRCLK and BCLK were generated from the MCLK using just dividers in the CPLD. The LRCLK of the BBB and the MCLK (switched oscillators from your driver) were feed to the CPLD. The BBB-LRCLK was used to synchronize the LRCLK the CLPD was making to the "correct" one the BBB provides otherwise it wouldn't be aligned to the samples. (Think of BBB LRCLK as a one time trigger).

So I basically through away the 2 BBB clocks (BCLK and LRCLK) and used these CPLD clocks. I could do this because the I2S interface was a slave to the MCLK. The MCLK was fed to the same places in both the BBB and CPLD case.

The resulting spectra was practically identical. This is strong evidence that nothing is different with the MCLK, LRCLK and BCLK between the two cases. If the integrity of the MCLK is good then it implies the data pin is the one at fault. Hence missing samples.

This hypothesis is supported by the fact at 48 KHz using the on-board clock vs using my off-board 48 KHz low phase noise clock I think also resulted in the same spectra. This suggests the limiting factor is not the MCLK (a bad MCLK could limit all cases technically). I would have to double check this to be absolutely sure but this is what I remember from weeks ago when I did this work. I do not believe the MCLKs could be bad. The "good" I2S USB source uses the exact same clocks as I selected to used with the BBB.

That would leave only: two defective clocks (both the 48 and 44.1), thermal damage during soldering causing several orders of magnitude worse phase noise than specified, and terrible PCB layout for MCLK. I don't believe any of those are particularly likely but they are technically not excluded by the experiments done.

[quote author="miero"]
Quote
I honestly believe it is dropping samples occasionally.
BBB and Botic driver, right? Does this also happen with 44k1Hz or 48kHz stereo streams?

If you use aplay it reports underruns, when there is not enough data to be sent to kernel. If underruns are reported then there is slow media, slow CPU for resampling/decoding or insufficient buffers sizes.

The problem could also happen in the kernel if samples are dropped without any report by aplay. For example when CPU is busy handling other interrupts (net, mmc, usb...), or when audio data rate is too high for the BBB.

The fastest file access seems be when remote storage is mounted via NFS. Then cifs (windows shares) but I had to set cache=none option to fix underruns with aplay.[/quote]

I am mainly testing for red book as the majority of audio sources are red book derived. I have also tested at 48 KHz. (So basically 44.1 KHz 16 and 24 bit and 48 KHz at 16 and 24 bit with most of the testing at 44.1/16).

How do I check for the underruns? I didn't notice any messages to that effect but I might not have looked in the right place or set the right switch (I am not a linux audio expert just a physicist/EE).

Is there a way to know if the FIFO for the I2S port underruns via software? (As in it sees the empty flag on that part of the IC when it is loading the FIFO or something like that?)

Finally you mentioned something about CIFS and other network file systems. Though the commands are sent over the network. The actual file played was on the local file system (microSD card).

Is there any way to check if the kernel is dropping the samples? I agree that other interrupts could cause drops if things are not written in the best way. I don't really have anything running on the BBB except standard OS stuff and aplay. (< 5% utilization).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on June 26, 2014, 12:06:16 pm
You can try a new driver for BBB: http://bbb.ieero.com/ (http://bbb.ieero.com/)
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 26, 2014, 01:49:23 pm
Is the source of the new driver available?

I liked the patch way much more than a whole distribution. (though I will try your distribution version at some point, and it would at least mean everyone testing is configuring things basically the same way).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on June 26, 2014, 01:57:01 pm
Yes, patches for kernel 3.15.1 are available in the /sources directory on the image. Or you can take kernel zImage, dtb file and modules and use it in your distribution.

But for the start it's better to use common environment until all issues will be resolved, that's why there is whole distribution.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 27, 2014, 01:00:17 am
Yeah that makes a lot of sense. I hadn't download the whole distro and looked for the sources. Thanks for the heads up as to where they are. I'll try it out as soon as I have time, maybe all the issues I have seen will just go away. There is some wishful thinking...
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 27, 2014, 06:05:41 am
I have done some simulations of dropping samples in ways the BBB might do. They look far more like white noise than phase noise though. If I didn't make any mistakes that means I will need to rethink what the experimental data has shown. I thought I had controlled for everything but the data pin, but maybe I overlooked something. I already mentioned some ways that it could still be one of the clock pins as well. For instance the drive strength of the push-pull circuits on the BBB vs the USB interface, what is weird about that though is the marked difference between running it from BBB vs a linux laptop, electrically those things are identical. Although they do have different power supplies. Perhaps I have to revisit power supplies again... When I first did that the results were much worse (could have covered this up). Anyway it requires more thought on my part. Showing development raw, as in this log, means that sometimes conclusions prove erroneous. I am going to make a new version of the DAC soon anyway at which point it might make sense to revisit all the measurements. There is also a new driver to try out. As time permits to anyone following this thread...
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 07, 2014, 05:22:45 pm
Any news?
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 16, 2014, 12:13:27 am
I've been busy as of late, didn't think to check here for some time...

Since you ask. I redesigned my DAC board and segmented it into 3 parts. Clocks, the converter and isolation method.

This will allow me to independently test things. For instance I can compare different clocks to each other. I can compare different isolators, or not use an isolator and deal with possible noise from ground loops from the BBB.

I will try using your new driver when I have the new boards in hand. I will also recheck the power supply stuff just in case.

This design will not the the final version. given how I did it, I will likely have to do at least 1 more version. I may have to also check the new flavor of R-Pi out at some point. I haven't looked into it enough to know if a MCLK will now be pinned out, but in any case the clock on the board isn't very good (unless they do much better) and the FPLL that generates the clocks is pretty bad so probably BBB will be the way forward.

The soonest any of this will get done is probably the 27th of July given I don't expect boards until ~7/20.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: ralfnap on July 25, 2014, 04:16:16 pm
Very good and interesting blog

Have you examined the alsa.conf file?
...
defaults.pcm.dmix.rate 48000
...

Try to change it to 44100.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 27, 2014, 05:05:34 am
That could be an issue I guess with the USB results but given the 48 and 44.1 files have basically the same spectra it isn't the issue for the BBB tests. I am 99% sure I looked at the hwparam directory while things were playing to check if there was any re-sampling for the BBB largely to make sure that the clock board was working. Everything checked out.

I did a quick test with the new design I made and with independent linear power supplies for my new board and BBB. The results are basically the same. Only thing really left to check is the new software. See if that does anything. I still think the jitter/phase noise is software/BBB I2S stream related so there is some hope of a software fix.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 27, 2014, 07:27:19 am
(measurements)

I'd like to show fresh measurement of BBB I2S output when connected to TPA Buffalo3 (ES9018) DAC. The used soundcard is ESI Juli@, software Arta running under Wine on Linux.

The BBB running Botic image is generating test signal using:
 $ play -V3 -r 96000 -b 32 -c 1 -n -c 8 synth sin 1000
No SW under-runs are reported by ALSA.

The BBB is powered from the DAC power supply - other rail of TPA LCDPS (with shorted R in C-R-C for higher current)

DPLL bandwidth on DAC is set to 128x highest, otherwise there were dropouts (LED blinks).
So it is possible that this DAC is correcting issues you are describing.

(driver)
It should be possible to detect BBB HW buffer underruns, but this is not yet implemented in the Linux driver.

EDIT: new image with better SNR (lower sound card input volume)
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 27, 2014, 07:55:16 am
Try to reduce 50/60Hz first...

[quote author="brian"](http://http://teholabs.com/docs/_media/openhifi2:cpldvsbbb.png)[/quote]
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 27, 2014, 11:59:23 pm
Hi Miero,

I have been using the new driver this weekend. No change for me.

I do get "play WARN alsa: under-run" sometimes when using your command. (Edit: I've uploaded a screenshot showing what I mean with the command context).

I had to use the serializer set to "4" to get it to play with "aplay someFile.wav" properly. However your command seems to not work if it is set to "4" but does work with it set to "-1". Is the "default" output DSD rather than I2S in "-1"? What should the PCM command for aplay be if set to -1 rather than 4.

Certainly your data looks better than mine. Although I will need to overlay it honestly because the lower the frequency the "better" a peak looks when on a linear scale (you have a log-log plot). Unfortunately I can't take a log fft so I'm stuck with 20 Hz bins...

As for the 60 Hz/180Hz/300 Hz spikes, I agree those are worthy of study. However, the uniform nature across many different setups causes me to believe they are in the meter sub-system rather than in the DAC (probably magnetically coupled to the transformer of the meter). Changing the DAC power from a bench HP E3610A to a simple wall plug makes no difference. The PSRR of my DAC board is something like 130 dB of rejection at that frequency as well. So I'm pretty confident that that junk isn't from the DAC design. (IE the ripple at 60 Hz would have to be 2 V on 3.3 V to be above -130 dBc if the PSRR is right, clearly that is not the case...).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 28, 2014, 02:06:48 am
Video updates:

General overview of project:
https://www.youtube.com/watch?v=hs5azFgPUkA (https://www.youtube.com/watch?v=hs5azFgPUkA)

Just measurements:
https://www.youtube.com/watch?v=EaMo72bXtRQ (https://www.youtube.com/watch?v=EaMo72bXtRQ)
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 28, 2014, 06:29:51 am
[quote author="brian"]I had to use the serializer set to "4" to get it to play with "aplay someFile.wav" properly. However your command seems to not work if it is set to "4" but does work with it set to "-1". Is the "default" output DSD rather than I2S in "-1"? What should the PCM command for aplay be if set to -1 rather than 4.[/quote]

That command plays at all 4 serializers (8 channels). For just stereo reduce no. channels using "-c 2". You can add also volume control by "vol -12dB" to the end, e.g.:
$ play -V3 -r 96000 -b 32 -c 1 -n -c 2 synth sin 1000 vol -12dB
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 28, 2014, 06:47:59 am
[quote author="brian"]I do get "play WARN alsa: under-run" sometimes when using your command. (Edit: I've uploaded a screenshot showing what I mean with the command context).[/quote]
Ok, I'll try to investigate (and fix) that.

To have at least somehow "comparable" results I've created also linear frequency spectrum plot of 7200Hz signal on my soundcard.

Btw, thanks for videos. You have nice boards.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 28, 2014, 08:32:20 am
Thanks for the extra data. I will look into this more as time allows. I tired this software you are using with an old 24-bit Envy sound card I had but there were clear indications of clipping in the spectra. Maybe I can try to volume commands. The 60 Hz and low freq components were not present but until I have more confidence in a calibration of sound card data I won't publish it.

The Buffalo DAC you are using while expensive (300 dollars), isn't wildly different than what I have (I think in terms of core technology), although I presume you have some IV stage for it since it is current output. Your sound card is far far better than anything I have access to at the moment. I can get the phase noise to look "good" with the sound card FFTs of course by just dropping the carrier power.

On the seralizer setting thing. I mean if I have it set to "-1" and I just call "aplay 44p1waveFile.wav" it will output garbage. If it is set to "4" it outputs normally with the same command. This makes me assume the default output mode is different for ALSA between these two settings. Is the default output mode under "-1" DSD streams?
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on July 28, 2014, 08:59:53 am
I request to use http://www.diyaudio.com/forums/twisted- ... river.html (http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver.html) for driver support question (to be at common place), but I'm going make one one exception in this case:

The -1 for sermask equals in terms of settings to 1+2+4+8 thus stereo playback is just on the first mcasp0_axr0 pin. Other pins should be silent (EDIT: more probably floating).

(subjective line) Last time I've checked ODAC (on PC), the Buffalo was better. I can repeat experiment with BBB and new speakers.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 28, 2014, 03:24:21 pm
Ah. I see my mistake now. The default pin for a stereo steam was moved. I looked at it on the driver page but missed it somehow. Your string is mixing the one stereo steam to 4.

I'll post future questions to the diyaudio thread. I can understand you wanting it all in one place.

ESS gives a better spec for the DACs that Buffalo is based on so no surprise if it is better than ODAC if the design is well done.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: trimpot on July 30, 2014, 01:48:00 am
Are there any updates on this investigation?  This is a good read.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 31, 2014, 03:30:47 am
Hi Trimpot,

If you want to follow along updates most often occur on the weekends. Though some weekends I like to do things other than electronics... shocking I know.

I got a chance to look at my latest design on an old dynamic signal analyzer though...

There was concern if the 60 Hz and other noise at low frequency was real. I strongly felt it must be in the Keithley 2015 when combined with the environment of my apartment building. This was hinted at by many things including a sound card type measurement, but attached is solid proof. A quick measurement on a dynamic signal analyzer. This system effectively only has a promised SFDR (spurious free dynamic range) of 80 dB. The signal was at 1 KHz -1 dBfs (which is 4.84 dBv for this DAC). At 60 Hz -86.05 dBv. So in dBc we have 90.84 dB. Which is 10 dB better than the SFDR promised. There are no peaks here at all.

The first harmonic was at -81.37 dBv which is greater and there was a tiny bump but this could be due to THD of the analyzer as it is still better than the spec.

In short the low frequency spikes seen before are indeed not a function of the board design, nor power supplies used (I used the same ones).

The question remains open of how to better measure this design. There are some demo boards from Linear and probably Analog devices that could be used as cheap(er) samplers. Calibration is an issue there but a bit less so than with sound cards.

Next most likely step is a comparison of different clocks, 44.1 family clocks in the range BBB can accept are limited in choice it seems. One lower cost alternative will require me to make a different type of clock board but that is why it is modular right now. That board is tiny and thus inexpensive to make variations of. MEMS clocks are available at the frequencies needed. Though typically one of MEMS clocks main draw backs is phase noise. I sort of indirectly know the people at Si time who make most of these clocks and are competitive with mass produced XOs in many cases.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on August 02, 2014, 03:27:52 am
Semi-related update.

My website blew up. Well sort of. I guess it had never lost power in about a year and something died on reboot. They no long supported Arch images (so I had to switch distros) and it wasn't easy to figure out what part of the configuration was messed up. So I just built a server up from scratch quickly. No more blog for now on teho Labs, just to simplify my deployment since I wasn't using it recently.

From the point of view of this thread all the spectra should be available again! This is how I realized my website was down.

Found an interesting clock to try and ordered some, but one frequency won't be available for about 60 days... At least these have easy to use supplier though! We shall see how they work when they get here.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on August 29, 2014, 07:39:15 am
In case people are wondering what is happening with the project, I thought I should give an update. I'm currently hunting for a better meter to measure the design with. There are a bunch of options I could take to move forward, and I'm pondering which is the least risky to by bank account.

Meanwhile I am working on a new project that is in support of this one, so never fear this one will be completed. I still can do isolator, no isolator tests and I probably will do them soon.

Also I tested my alternative clocks and they very well based on what I can measure and have the virtue of being 1/4 the price.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on September 25, 2014, 06:50:45 am
I wanted to just say this project is not dead. I have a better meter now and will move forward on it when I have a moment to catch my breath, I've become super busy with other items right now, but I hope to finish the project before 2015.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: ro9 on October 09, 2014, 12:31:25 pm
Hi!
Great to hear that the project is still active!
Is is possible to boy your prototype at anytime?
I would for sure like to test it in my audio-setup at one time.

I have an old North Star Dac 192 - which has an i2s input - which i am currently feeding from an USB/SPDIF konverter - but the thought of an even shorter audio chain is very compelling to me :)

Br
Ronni
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on October 11, 2014, 09:38:30 pm
You certainly could use just the DAC board in that application. I don't have any spare prototypes at present. I'm sorry I've gotten so busy, but that's just how things go. Holidays should give me some scope to work on these designs. I have Columbus day off on Monday but this weekend is already eaten by other tasks. I have off Nov 11th and 27th. Its possible I will get something done on this on one of those two days.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jharp on November 14, 2014, 11:19:05 pm
First, a big thanks to Brian for this topic and his posts, and all others who have posted.  Very interesting!

Please note that I am new to this site, and it is unfortunately complaining about off-site URLs in my post, so I have removed them.

I landed here while researching options and ideas as I ponder building a BBB-based audio player.  I'm a computer scientist with some EE knowledge, but certainly not enough to design a production quality audio cape.  I do have many years of practical, seat-of-the-pants experience with embedded systems.

My interest in basing an audio player on BBB is purely practical - I already have some sitting around from previous projects/R&D, so I wanted to try to use them rather than buying something else.

I'm a bit skeptical because it just seems excessive to be using Linux and a powerful SBC like BBB to create an audio player.  But there's no question that having Linux offers the potential to make some aspects of creating a working system with a good user interface and flexible communications options much easier.

I'm still in the earliest stages of this and trying to hash out what approach I will take.  Brian's initial post resonated as he discussed using FPGA, one scenario that occurred to me.  Another potential scenario is using something like UDOO and offloading some responsibility to Atmel SAM3X8E.

My gut feeling is that there's likely to be a benefit to shifting some processing responsibility away from the main SBC processor, regardless of what interface is ultimately used to communicate directly with the DAC.

Some time ago, while researching issues for a BBB project that involved data acquisition, I found a post on element14 forum site titled "BBB - High speed data acquisition and web-based UI" dated August 2013.  Sorry that you'll have to search to find the URL.  But it's an interesting read.  What interested me most was the use of one of the TI AM3358's PRUs for offloading I/O duties.  This approach, if used in the other direction, is another scenario I'm considering.

Wondering if Brian or others have any feedback on any of these scenarios, aside from FPGA which has already been addressed.  Might be worthwhile to experiment with, if for no other reason than to provide an alternative approach to compare against.  In theory, the basic idea of offloading in some form should clear up any problems rooted in TI I2S signal generation or OS buffering I would think.

Thanks,
Jeff
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on November 15, 2014, 04:30:07 am
Hi Jeff,

I got a PM from someone so I came to answer it and then I came to check on this thread. This project is alive and well, I'm just completely out of time right now. I've written over ummm maybe 400 pages of documents in the last two months and am working on filing a series of patents... so I just haven't had time.

I don't recall what I originally said about FPGAs and so on. But let me give you just a few quick thoughts here.

The reason I decided to abandon my original microcontroller based approach was the cost of software. Software has huge maintenance costs in terms of time. The reason I choose to try to make raspberry pi work first was it had a larger user base. That larger user base means software will be around and people who can offer support for software longer. If you create a fully custom solution it might be more elegant and less expensive. If you are going to sell a million units that might well be a great way to go. If however you think you might have 10s to 1000s of people interested then using something that other can easily hack is probably better, even if it is overkill.

One version of a "headless" player I considered building was a steaming wave player. Then the hardware is ridiculously simple and all the work is in the "server" software. The player is nothing more than a wifi connected DAC for a wave stream that relays commands to the server. I didn't settle on this approach because I didn't want to spend a lot of time writing software and because I wanted to avoid the need for having a "powerful" computer online all the time. In some sense I still do, its just physically connected to the DAC. But two boxes is two enclosures and more clutter. All that will be needed for my design will be one neat aluminum box, a smart phone/tablet (the remote control) and a network attached hard drive.

As far as the jitter issues with I2S streams. FPGAs and all circuits have inherent jitter. Its specified, and you can look at the eye diagrams if you like. Folks to design audio ASICs think about these issues more than FPGA designers so it might not the best solution, however I note that if you can't measure the difference in an FFT there is no difference. One really should only need to measure sort of the standard distortion and non-linearity quantities that are used in RF and the noise sources to fully characterize such an interface.

I should get back to this project in the winter months, though the holidays could continue to keep me away from additional work on it. I can practically give complete assurance that this project will be finished at some point because I have promised people I know units when complete and I have purchased additional test equipment to continue the analysis.

Brian
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: jharp on November 15, 2014, 10:45:09 pm
Thanks Brian for the update.  You are really busy!

I'm in no rush.  Just doing research at this stage.

I'm not even sure of more basic question of buy vs. build.  If I can find what I want pre-built at sensible price I will buy.

I went through this same process 2-3 years ago, coming close to getting an ODAC, but after looking into it more thoroughly and researching software issues, I put the project on back burner.  Now, and then, my time is limited to allocate to side projects that don't generate revenue.  I was looking for something fun to do, but got so frustrated by the state of things at the time that I decided to walk away.

Things have come a long way on software side, which is nice to see.  On hardware side, particularly DACs, it still bothers me that there is so much subjective nonsense on forums about DAC A sounding better than DAC B.  Objective analysis is hard to find!  That's one reason this topic caught my attention.  Wish someone would launch a site with objective reviews of DACs and related gear.

Been reading a lot of stuff under TPA section of diyAudio site.  Now I realize that you are connected!  Is the work you're referring to here the "Botic cape" being discussed with so much enthusiasm and antcipation over there?

I remember a post by Russ White around August stating that boards were "ordered".  But then I went back to very beginning to read from the start and there are so many posts I haven't gotten to end yet to see where things stand today.

Maybe a KickStarter campaign or something like that would be good way to bring in funds to allocate more resources to the effort and accelerate release/launch?

Are there any kind of specs or design documents available on-line for this board?  Maybe they are referenced in the diyAudio topic and I just didn't get to them yet.

I've downloaded as much software as I could find so far for BBB audio, including work from miero and lintweaker, and will spend some time studying and trying to get up to speed.  With all the downstream changes being made I feel I want to understand that before proceeding with BBB as my platform.  I also want to get familiar with various audio formats, decoding, and resampling issues, things I don't have direct experience with.

I would be glad to contribute in some way, but not sure what I can bring to table that you don't already have.

Thanks again to you and other contributors for all your work on BBB audio player hardware and software.

Jeff
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on November 15, 2014, 11:16:03 pm
jharp: There is a difference. Brian here aims for complete low-cost DAC addon for BBB, while projects on DIY audio aims for I2S/DSD transport only.

The original "Botic cape" was obsoleted by more complex project and the Botic is now just name for Linux audio driver and configurable SW platform for generating I2S/DSD/SPDIF signal using BBB.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: bandy123 on December 12, 2014, 02:07:51 pm
There is an I2S dac board complete design here, including the circuit, for the beaglebone black: http://www.element14.com/community/comm ... ding-a-dac (http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/07/06/bbb--building-a-dac)
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on December 19, 2014, 01:31:56 am
Yep. I saw that post a long time ago. There are several other examples in the web as well. You can use any I2S DAC with BBB and there are millions of those on eBay. The caveat is that you can only do 48,000 Hz family with the clock on the BBB board. This means resampling audio typically in a not great way on the fly for regular red book. Also the quality of the DAC design will matter a lot.

Your mileage may vary.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: bandy123 on December 19, 2014, 01:50:17 am
What are your specific requirements? There are 61 posts in this thread so I may have missed it, but I thought you'd discounted that DAC because of the PLL, but the element14 design doesn't use the PLL inside the DAC, it has been disabled. Also, it's not a big deal that you can only do 48k because the BBB uses an external crystal oscillator on the board according to some comments on that site. This could be easily disabled, and feed your own oscillator. According to some of the comments on that page, the BBB's internal hardware is extremely flexible (and it certainly looks it according to the processor manual) which surely makes it a good board to consider for feeding a DAC?
Finally, regarding quality, it is the same DAC as used inside Sonos, and a Meridien device according to that website (5-star ratings for the Meridien according to some British hi-fi magazine here: http://www.whathifi.com/meridian/explorer-dac/review (http://www.whathifi.com/meridian/explorer-dac/review) ). Again, apologies if you did have specific requirements, but I went by the title and the few dozen comments I did read in this thread..
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: bandy123 on December 19, 2014, 02:51:14 am
By the way, there is a recording of that circuit on the same site (direct link to the zipped MP3 file): http://www.element14.com/community/serv ... output.zip (http://www.element14.com/community/servlet/JiveServlet/download/38-126336/dac-output.zip)  which is the analog line output from the DAC fed into a sound card analog line input and recorded. Sounds good considering this had to be re-digitized through some PC soundcard! and then converted to an MP3 (it says 320kbps). The source file was an MP3 file too from Amazon (the link is on that site) so it could be compared.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on December 19, 2014, 03:06:33 am
I am focusing on objective measurements of the whole system to achieve transparent performance, in a similar manner to the ODAC. You can design a DAC board that works with BBB or R-Pi in under an hour, its designing one well that is harder. Check the ODAC out and read all the posts in this thread if you want more details as to why. Getting to about 80 dB THD+N is very easy which is where a lot of consumer grade audio things actually are. Getting to over 90+ dB is hard and requires care in design (Edit: ODAC reaches 90.5 dB).
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on December 29, 2014, 03:55:17 am
Update!

I know it has been a long time coming. To those of you following this project I thank you for your patients.

At the end of summer I acquired an audio precision one analyzer to continue this project. However I was so busy that I hadn't had the time do more than turn it on and make sure the fan was working in spite of the high cost of the unit (for me) until today.

I am happy to report that while slow I have a GPIB program that takes FFTs with this guy and everything looks superficially correct. The big improvement here over the FFTs I was taking before is there is a proper notch filter in this unit allowing better THD+N measurements.

I cannot say I have tested the unit thoroughly today but I talked to it, messed with the generator and got FFTSLIDE working. I looked at an externally generated tone using a source as input and the amplitude seemed reasonable. A bit more testing is needed to be sure all is well but things look promising.

Once I complete testing I can go back and look at my PCBs with this instrument and get to the bottom of any deficiencies on an objective basis. I hope to have some time on weekends coming up. There are a few more holidays coming up so I may have more time then. Much of what was taking up my time in the fall is now over so hopefully progress will be more swift.

Also prototype cases were designed and are being fabricated. Hopefully they will look nice.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on January 05, 2015, 02:34:21 am
For those who are following this thread. I have new measurements. Hooray!

As I mentioned I have acquired an audio precision system one. I managed to get the GPIB model with DSP. Everything seems to be working but reading data is painfully slow for high resolution work (large numbers of FFT points). If there is a way to do a binary transfer with a single GPIB command I don't see it in the manual. So it goes at about 3 points a second. Not exactly speedy.

Nevertheless I had the time today to do some initial measurements with my modular DAC board. Since the best performance was with an external USB I2S interface I had in the last test that is where I decided to start to verify the integrity of the DAC PCB design and power supplies that supply it etc.

The results are more clear than using the Keithley.

(http://http://teholabs.com/docs/_media/openhifi2:ap1k.png?cache=)

Without the notch filter we see the limits of the converter in the AP Sys 1 unit in terms of THD.

(http://http://teholabs.com/docs/_media/openhifi2:ap1knotch.png?cache=)

With the notch filter on (taken at the same time but with the second channel) we see lower noise floor.

Calculating the THD+N over a bandwidth of 22 KHz the data suggests:
 >86.9 dB for 1 KHz @ -1 dbFS input (0.0045%)

This is below the maximum value (0.005-0.006%) in the ES9023 but above typical (0.002%). As can be seen from the data the primary issue is actually 60 Hz rejection. Followed by the first harmonic. The spike at 12 KHz I believe to be anomalous as it is present with no signal input.

Since the data falls within the tolerance for this measurement in the datasheet this is already acceptable, but I will explore the 60 Hz noise more before moving to two tone and other tests.

I also note of the residual THD+N contributions the the spectra is 20% line noise, 74% background noise floor, 5.5% first harmonic and 0.3% everything else. I will have to test the SYS-1 unit to see what its own background noise level is presently.

Once the DAC alone is fully verified I can return to the BBB tests and the mystery of the phase noise like signal spread.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on January 05, 2015, 06:08:10 am
A quick follow on to my last post. The DAC board currently has a cascade of LDOs, this is bad for the noise floor by about 3 dB, but increases the PSRR. Total it in principle has over 130 dB of rejection at 60 Hz, therefore it seems highly likely the RCA cables are picking up 60 Hz from the room to this level. Since 74% is background it may be wiser to use a single LDO rather than the cascade. If I reduce the background noise floor by 1/2 and remove all the line noise that should increase the THD+N by 3 dB. There is also 1 dB left full scale. The 1st harmonic will probably increase 1 dB or more if measured at 0 dBFS. Still it seems reaching ODAC in terms of THD+N is could be very close at hand.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: snoozer on January 12, 2015, 02:44:53 pm
Hello Brian,

thank you very much for sharing your work, I am a fan of your posts here ....  learning a lot with your experiments and measurements. Keep it up !

I am feeling very intrigued about the possible missing samples with the BBB .... really looking forward to fully understand the mystery of the phase noise :-) Please don´t forget to post your results

best regards
Pepe
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: snoozer on January 12, 2015, 03:01:58 pm
Brian,

between the two USB i2S sources you used for your tests, could you please share which one is the one that tested better ? (maybe XMOS based?, just guessing..)

best regards
Pepe
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on January 12, 2015, 10:46:04 pm
The best one I have is based on CM6631A, I don't want this to be an advertisement for one or another though, just like companies do "competitor A" and B, I should. Because honestly a lot has to do with the clocks selected and the board design potentially. I note performance of this usb interface is bad when used with BBB or r-Pi as I recall. But was fine under Arch with a x86 laptop. All tests are windows for USB interfaces in general.

I should return to testing with the BBB soon. Now that I have absolutely clear spectra I can proceed to fix some issues. I already have decided to change the LDO config and bypassing somewhat on the next version of the board.

I might do some tests with the external clocks using the async mode with the external usb interface to understand the phase noise of the clock options if the phase noise like signature remains in the BBB output.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on February 15, 2015, 03:03:35 am
I just wanted to give an update that I expect to get back to this in March/April. I am sorry it has taken such a back seat, but I have machined cases for the design now. I am unfortunately traveling most of the rest of this month so there is no possibility of progress until March really.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on April 13, 2015, 06:58:53 am
As per my last post it is now April so I had a little time to do more work on this. Rebuilt the clock boards and stuck with the external I2S source for now.

No difference was seen between two very different cost clocks for MCLK. Now this would effectively use the DAC asynchronously and the other signals are all still from the same clock however its reasonable evidence that I need not spend money on the more expensive clocks for this design.

I switched to my simple wall DC supply from a bunch power supply and the 60 Hz noise is worse though I note as before that could be for other reasons. The numbers don't really add up properly given the amount of PSRR that should be available at 60 Hz.

I need to probably switch to BBB next and see if I can witness any difference with the two clock sets.

I think I mentioned that I have the cases so the next version of this will fit the cases and perhaps be the last PCB version if everything looks nice.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: htito on April 30, 2015, 09:31:38 am
Nice project. And when the last PCB version ?
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 17, 2015, 07:29:35 pm
So... I am moving across the country for a new job. Things are rather busy here as a result, and things will be busy there as well for at least the first 6 months I should think.

This leaves not a lot of time to do this project! Eeep. Therefore, this weekend I redid the PCB in hopes of finishing the project to completion before my move.

I didn't have time to fully compare the isolated vs not-isolated variations but I did check that two different types of clocks were basically the same if used with the external USB I2S source. This isn't a 100% proof that I don't need to use the more expensive clocks because the USB I2S source has its own clock to generate 3 of the I2S signals and with the clock swapping only the MCLK is really being changed. However it is the best I can do, in the time I have.

I'm sure there has been progress on the drivers as well. There is milled Aluminum case this whole thing sits in as well. If I didn't mess up the geometry of the PCB any then it should all be ready in about 2-3 weeks to show what the final versions will look like.

In June hopefully I will put together the PCB and it will both fit and work. If so I will make as many measurements of the design as I can and make a determination if any further revision is warranted. I have time perhaps for 1 more generation of PCB before my move.

The PCB is laid out so that I can do isolated and non-isolated connections for the I2S bus. I made the following changes:
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on May 30, 2015, 10:16:33 pm
I got new PCBs but there was a geometric mistake in the placement of the power jack so I had to order new ones. A few more weeks before new results because of this error.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on June 21, 2015, 07:44:52 pm
Boards are back, soldered, working and fit in case.

I am working out a few software issues with the new Botic drivers, then I will test the performance fully.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 04, 2015, 06:34:35 pm
I got all the software running nicely. Now I'm back to hardware. Couple little things, they all have little fixes I can do without getting new PCBs, so I should be ready with all the results by July 12th I'd guess if not a bit before. Things look generally good though, nothing show stopping yet.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on July 12, 2015, 08:38:16 am
I would like to thank Miero for his hard work on the linux I2S driver for Beaglebone Black's SOC (http://http://bbb.ieero.com/) without the driver this project would not exist.

(http://http://teholabs.com/docs/_media/openhifi2:dac.jpg)

(http://http://teholabs.com/docs/_media/openhifi2:dacinbox.jpg)

You can see the design in its enclosure here below and in the following video:

https://www.youtube.com/watch?v=vzQap-tiD9Y (https://www.youtube.com/watch?v=vzQap-tiD9Y)

The design is essentially complete and tested as of 7/12/2015. Software and hardware are fully functional.

A kickstarter may be launched if there is large interest. The full design will be open source at the end of the project. I want to give it one more update to try to improve the right channel performance and do more to filter high ripple power supplies.

As of 7/12/2015 only intermodulation tests still need to be performed. Given the other results it is highly likely they will be similar to the ODAC (http://http://nwavguy.blogspot.com/2012/04/odac-released.html).

Tests were performed with an Audio Precision System 1 (SYS-222G) with 24 bit files at 44.1 KHz.

A typical spectra for the DAC driven by the BBB at 1 KHz -1 dbFS is shown below:


(http://http://teholabs.com/docs/_media/openhifi2:1khztone.png?)

Here there are plenty of harmonics, but these are due to the dynamic range of the converter circuits in the AP-1 interface. The notched path shows the true signal components, note the change in the y-scale:

(http://http://teholabs.com/docs/_media/openhifi2:1khztonenotched.png?)

As we can see here the spectra is very clean. The change from a cascade of LDOs to a single very low noise LDO has improved the noise floor and with it the THD figure. Here is is < 0.003%. This is the left channel of the DAC. The right channel shows a larger first harmonic signal the reason for this is not obvious from the board layout but will be investigated in the future.


Also of interest is the flatness of the frequency response (at -1 dbFS):

(http://http://teholabs.com/docs/_media/openhifi2:flatness_m1dbfs.png?)

The flatness is essentially +/- 0.1 dB exactly the same as the ODAC. It is actually louder than the specification at low frequency. Here 0 dbFS = 1.9 V as the design is being run presently at 3.3 V rather than the 3.6 V of the ODAC.

Along with the sweep of the frequency response, a sweep of the THD can be done using the voltmeter inside the AP SYS-1 after the notch filter:

(http://http://teholabs.com/docs/_media/openhifi2:thd-lr.png?)

As can be seen the right channel is higher than the left. Inspection of the spectra show that it is largely due to a higher first harmonic distortion component. Further study of this may be needed to understand the source. I note however that although this is a mystery it is still a very low distortion number and already better than the amplifier that I own (thus transparent). 

The left channel starts at 0.0035% with a minimum of 0.0024% and peaks at 0.0048%.
The right channel starts at 0.0051% with a minimum of 0.0043% and peaks at 0.0058%.

The dynamic range at -60 dBFS was also measured, here it is plotted notched with A-weighting applied.

(http://http://teholabs.com/docs/_media/openhifi2:m60db1khzdr_aweighted.png?)

With A-Weighting the dynamic range is 104.8 dB. This is greater than 16-bits (96 dB), and thus more than my goal since the vast majority of audio sources are derived from Redbook audio.

Theoretically 112 dB is possible for this figure, the ODAC got to 111 dB with whatever USB power source the creator had. This figure will depend on the power supply used and is part of the reason I have added a TODO item to improve the power filtering.

Crosstalk is well controlled at 10 KHz:

(http://http://teholabs.com/docs/_media/openhifi2:crosstalk10khz.png?)

The datasheet says we should get 100 dB and that's essentially the result. The actual figure is 99 dB at -1 dbFS, so the figure is isolation is 98 dB. More than enough.

THD at 0 dbFS at 100 Hz was also measured. No increase in distortion was observed with the current design.

This design is essentially transparent for minimal cost and usable directly with a BBB. The primary cost is the milled aluminum case.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: miero on August 02, 2015, 02:21:23 pm
Congratulations Brian! :-)

What about its sound, does it fullfill your expectations?
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on August 06, 2015, 03:58:40 pm
It sounds as you would expect very very good. I had a minor issue with a capacitor being of the wrong type and the THD was higher until I noticed I put in the wrong kind (not by much but some) but because this design is better than my amplifier (or my ears) I honestly didn't hear the difference, I could however see the difference in the objective measurements immediately.
Title: I2S DAC board for raspberry pi and beaglebone black
Post by: SvenHz on September 05, 2015, 07:53:11 am
Hi Brian, I would like to get/buy/build one of these! What are your plans?


Sent from my iPhone using Tapatalk
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: brian on October 07, 2015, 11:03:45 am
My plans are during semester break I will finish this project (Dec/Jan) Too much until then. sorry.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: bandy123 on October 08, 2015, 05:17:40 pm
Hi Sven,

There is a beaglebone DAC schematic, parts list and gerber files here if you can't wait till then:
http://www.element14.com/community/comm ... ac--part-2 (http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2014/02/09/bbb--building-a-dac--part-2)

There is also a recorded file to hear the actual output before you choose to build it:
http://www.element14.com/community/serv ... output.zip (http://www.element14.com/community/servlet/JiveServlet/download/12354-126336/dac-output.zip)

According to that page, "This was directly recorded from the headphone output" and it gives a link to the original source music file for those interested in doing a comparison.
Title: Re: I2S DAC board for raspberry pi and beaglebone black
Post by: SvenHz on November 30, 2015, 11:25:47 am
[quote author="bandy123"]
There is a beaglebone DAC schematic, parts list and gerber files here if you can't wait till then:
[/quote]
Thanks for the suggestion. I'll patiently await Brian's developments. I am a big fan of his methodological and fact-based approach to this.

I am unable to find similar measurements for other DAC designs...? An alternative for me personally could be a Audiophonics.fr Sabre I2S DAC board with precision clock for RaspBerry Pi, but again, still looking for objective measurements ;-)