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.
[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.
After my disappointment with the Raspberry Pi's phase noise performance I decided to take a second look at the BBB. Firstly because it is a more powerful CPU and is more open if I am forced to use USB audio. Since I first started this worked out what I need to do to build up a ARM Linux system on Arch that runs MPD etc. So I thought I would just try the USB audio enumeration. I can't remember if I played anything with it under USB but ALSA found the low jitter USB interface fine.
I then promptly got distracted with the I2S on the BBB again. I went back and reread the posts I already linked to above. I was very tired and frustrated by the end with the BBB last time and this is partly because I did not read carefully enough. Essentially what is likely is that not building the system from scratch myself I didn't have matched kernel modules last time. This time everything was built up by me from base Arch so I made sure everything was matched.
In short the Botic I2S driver does work fine. The only issue is that you only have an integer clock divider and so it only does 48K family frequencies with the clock on the board. 44.1K family frequencies are sample converted. They are certainly causally lessonable. (Also I haven't checked if the I2S clock is inverted from what it should be as per one of the referenced links before on BBB).
The phase noise of the clock on the BBB is better than Raspberry Pi by far... Again with the same DAC comparing this time the BBB (blue) and the best I2S usb interface:
My next step is to make a clock board to create external clocking for the BBB and see how well that works. USB audio is okay but in the long term it is a more complex and costly solution.
My hypothesis from the last post has been verified:
Upon seeing what I felt was obviously phase noise/jitter in the previous data I went out and purchased 2 USB-I2S interfaces that would be compatible with my DAC design. The results are stunning as can be seen above.
I still use the same commercial CD player as a reference for the comparison. This isn't a 2000 dollar CD play or anything but it is a product designed by an audio company who's engineers had plenty of experience. It appears that a USB audio I2S interface plus my DAC is now superior. Someone in my family has a very expensive Rotel CD player it might be interesting to look at the results of.
I believe the displayed average noise level (DANL) on the FFT is now just the limit of the converter in the Keithley meter. There is evidence of non-idealities though, for instance there is a 60 Hz harmonic at only -73 dB. This is unweighted. The more typically reported A-weighting (which has massive flaws apparently as a measurement) would lower this by weighting it -30 dB. For a 1 KHz tone the first harmonic is at -89 dB vs a signal of -1 dB. The rest of the harmonics appear negligible so the THD is about -88 dB. Again this is an unweighted estimate. If you assume a median DANL of -102 dBfs for all 1000 points in the FFT the SNR can only reach -72 dB unweighted. This chip design is likely to be closer to -90 dB therefore I probably need better measurement equipment at this point. Although I can look for the source of the 60 Hz noise still.
One huge take away here though is that: pretty much no solution that uses an unbuffered I2S stream from a Raspberry Pi will be high performing.
I am now looking at the source code of the Kernel driver for the I2S stream, it perhaps could be a software issue but more likely it is the quartz used or the internal jitter of the BCM2835 F-PLL circuits. It does not seem that the makers of crystals specify much in the way of phase noise. For oscillators yes but not for the crystals themselves. The Q of the crystal and its number of 2-level systems clearly would affect phase noise properties. The best performing solution in the plot at the top of this post uses very low phase noise clock. The CD player and other source just probably use pretty good clocks. Clearly the clock on the r-Pi is terrible. Probably if I desolder and replace the crystal with another 19.2 MHz clock the performance will go up at least to the level of the CD player/lower performing USB I2S source. I cannot find out if the BCM2835 will allow a oscillator in place of a crystal on its inputs. Sometimes this is allowed. It is very unfortunate that what is basically the default board for computer on a board/module is from an extraordinarily closed company (whereas BBB is completely open).
Data has arrived. My solution for taking the data was rather crude but I collected data at points 100 Hz apart from 20 Hz to 20 KHz. This was done with the Keithley 2015 as mentioned in the last post.
The results were interesting. The data was taken with a 16-bit FLAC file with a stepped tone sweep. This was synchronized to the data collection script using timers, a crude but effective means of getting the job done.
Data was collected using two implementations of the ESS based DAC, as well as two sources the Raspberry Pi and a Procyon board which was running the openHiFi project I wrote several years ago. Finally I took data with a commercial CD player which had the FLAC file burned to a CD-R.
Here is the result at about 7 KHz:
The worst result is the Procyon + ESS DAC, the best result is the CD player. The two versions iterations of the ESS DAC board are similar. The small shift in the frequency is because one dataset was collected at 7.3 KHz and the others at 7.2 KHz. For the present purposes the noise floor is what demands attention.
This is a bit complicated because on the 2015 to take this data you actually ask it for a distortion measurement of 20 Hz. This gives it the finest FFT it can do (20 Hz per point). It normalizes the spectra to the value at 20 Hz in dB. Since this is in the noise this means the peak value is comparable one acquisition to the next. This problem is remedied by simple normalization of the data based on the peak value. Leveling is easy to check with the RMS AC function which compares correctly to an LeCroy oscilloscope. The CD player output is nominally 1 dB louder than it should be (or the burning software normalized the disc on burning as the reference level was set to -1 dB full scale on the tone track).
This method works well given two different PCB designs yield almost the same spectra using the same source and DAC. There are some limits to the 2015 meter which may cause issues down the line but it has already revealed weakness of the integrated design. Without the objective measurement we might accept this system sounds good but the reality is that it is objectively worse than a rather old shelf CD player! To test to affect of the source of the I2S stream Procyon was used with the same DAC and it was still worse! The most reasonable explanation for the FFTs seen is phase noise/jitter. At least that is what the data looks like. Phase noise on the bit clock would become less of an error as the frequency of the tone is decreased and that is observed. The ESS DAC is suppose to reject jitter and a very lower jitter clock is driving the DAC's MCLK, however no method can completely remove jitter without completely reclocking the data and using a large enough buffer.
Sounds like you might not need any more options but as I said I have a bunch of old stock and I am not in that business anymore if you want one (or many) of them I can see what is around.
FAT was demoed in USB and on the microSD card (Procyon only) in examples. Ti has development boards based on the same chips which are rather pricey. The new Teva ones are less expensive but I don't know if there is any host capability. If you want open USB stack NXP will be the way to go probably.
The documentation styles of NXP and Atmel are very different. In general NXP development boards are less expensive than Atmel's home grown ones. AVR 8-bit is super heavily used but not as big a user base for their cortex stuff.
Lpc Xpresso is sort of a free-ish toolset for NXP's chips. I have a development board for their M4 part which is a interesting dual core M0/M4 where the M0 might run the I/O and the M4 does the computations.
teho Labs (my company) used to sell M3 parts from Ti/Luminary Micro. I always believed these were the easiest Cortex parts to use and put up full how to guides on how to roll the tool chain with free stuff (so no code limits). I have a pile of boards (Eridani) that can do USB host if you want one. They may need some solder rework though and I won't have time right now to do that for you.
Ti also has a lunchpad for their M4 parts now called Teva I believe, but I haven't checked if they do USB host yet.
As far as docs, Ti, Atmel, ST and NXP generally always have very complete documentation, however the organization of those documents is very different company to company. You will probably find the largest user bases in M3/M4 with ST then Ti/NXP and last Atmel and Freescale (which I feel is less open).
NXP has ported the open usb stack from AVR8 to their micros so they have shown some actual support for open source.
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.
There is a lot of information on using the BBB as an audio player. This person however wants to make a "bit correct" version of the playback. The most interesting thing about the table (to me) are the quotes around "fractional clock dividers". I can only speculate he does not know about fractional PLLs.
Clocking and jitter on the I2S stream can be relevant in that phase noise will increase THD and smear a tone in the spectra of the output. One way to decrease phase noise would be to have a oscillator on board at each sample frequency and then switch them into the Ti processor on the BBB running as a slave. Meanwhile you would feed this same signal to the DAC. Everything would be synchronous to this. To support all frequencies would require many crystals. To lower the number of crystals a high multiple of the 44.1K and 48K series could be used and switched and all other frequencies generated by a counter/divider/integer PLL. This seems to be the approach favored by the author of hifiduino. Phase noise will still exist not only from the oscillator but from all of the inverters etc in the circuit.
Without the external slave driving of the I2S interface the BBB will resample to 48K family frequencies. This is not ideal as the interpolation method is not known. I am not sure if anyone has setup a driver to allow for external driving of this interface in Linux as yet. Given the completely open documentation for the BBB SoC it is not doubt possible.
My initial trial of the BBB has shown less than promising results. As noted in the first blog post series linked to, the bit clock for the data stream is inverted from what it should be in the current kernel. My test board is optoisolated, which makes inverting signals free, so I just fixed it at that point. This bug does show the lack of support for using this interface extensively among developers on the BBB. Most users are using USB DACs rather than the I2S interface.
I quickly turned on I2S by hand and found that for the settings in the Volumio distribution, that there was extreme distortion. I inspected the bit stream with the open logic analyzer to try to find the problem for several hours. The only item I saw were occasional flips of MSBs for just a few samples and then back. Interesting, the MSB was nearly always high. Also some frames seemed synchronized wrong to the L/R clock, but it is hard to say definitively without a more structured wav file than the ones I tried. The distortion was not present when the output was held fractional volume.
Also I must mention Rune Audio. It seems the interface for RaspyFi/Volumio was written by these guys but there was some unspecified disagreement between them and they broke up. Currently the documentation for both Rune and Volumio are lacking but I get the superficial impression that more is going on in the Rune group. Both groups would benefit greatly from opening up more.
Both Rune and Volumio are basically a web configuration interface and MPD client running on top of Linux with MPD. When I tired Rune out there was no baked in support in the web configuration for I2S so I had to configure MPD by hand. Because I had done this I decided just to try to setup a system without the web server part from scratch. I choose Arch because I like their docs and have built Arch systems from the base more often than debian ones where the distro comes more packaged information seems more scattered around.
A few hours later I had a working system, wi-fi, I2S, MPD, Samba, ALSA. So even if these projects go poof or don't improve my little widget will be okay because I can build a system now myself.
This prompted me to wonder if I did the same exact build for BBB (the Arch build was on raspberry Pi) if the distortion/clocking issue would be there. Others haven't reported it but it is possible it isn't my MSB issue but something with clocking and they used 4 wire I2S rather than 3 wire as I am. The truth is that the need for multiple external clocks is disqualifying in terms of complexity for use of the BBB. Therefore if I get back to try this out it will be when I have a lot of time on my hands. As much as I like the greater openness of the SoC docs for the BBB.
I also got through the hard part of writing a script to take FFTs with my Keithley 2015 THD multimeter. I will compare a calculated THD measurement from the FFT data to the internal routine in the meter. I expect them to give the same value. The meter is just sampling the voltage really at high resolution so everything other than that is almost certainly a calculation. If all goes well I should have a nice little python script to do automatic testing of an audio DAC paired with some test wave files for stimulus.
Finally, a compute module was recently announce for Raspberry Pi. I see some positive points to using it but for this application it would increase costs.
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.)
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).
Humm I don't think anything that requires tools would work really. I'm looking for something certainly that presses into place but perhaps the solution is more like pogo pins in that it is springy rather than snug and requires a vice. I can't change the PCB on the once side so I can't use offsets or anything to make things stick.
I need to find a solution for solder free connection between a normal 0.1" double row header and a second board. The second board can be soldered but the first cannot. I know of pogo pins but it would be better to have something more like a snap in where the pins flare out radially to make contact into the holes.
I've been sniffing around digikey for a bit but so far nothing as I don't know what they are called. I think I saw something like this on a teardown of an airbag sensor on eevblog. Any pointers would be most appreciated.
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.
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).
