There are many mixed analog/digital circuits today. Often the components like ADCs, DACs or codecs have separate power supply pins for analog and digital parts of the circuit. However, most modern opamp-based circuits have a very high power supply rejection ratio (PSSR). Does it really make sense to use separate power supplies for the analog and the digital part?
Let’s have a look at a specific example – our HiFiBerry USB. The PCM2906C from Texas Instruments used in this design can be powered completely from the USB bus. It has internal voltage regulators the create a 3.3V voltage supply from the USB bus voltage. But if you look in the datasheet, you will notice that Texas Instruments recommends an external REG-103 voltage regulator for high-quality audio.
Is there really a difference? Let’s see. For our tests we measure harmonic distortions of both the input and the output of this codec. Input and output are connected by a simple loopback cable. Input and output run at full swing (about 2Vpp).
We will start without an external voltage regulator. The chip is powered directly from the USB bus power.
0.01% harmonic distortion (D2) are not too bad. This chip is not the best codec available on the market. However, there is a lot of D6+ distortion peaking to 0.1%. That doesn’t look good. Where does it come from? Let’s see, what happens if we use a REG-103 voltage regulator for the analog supply of the circuit:
Much better! D2 and D3 are at about 0.005%, D4+ even much lower. This is a really nice-performing codec now.
There is also another interesting fact here: Even with the additional voltage regulator, the whole circuit is still powered via the USB bus voltage. With a high-quality voltage regulator there is no need for an external power supply, which is good news.
Today I did some measurement on the HifiBerry USB. The first measurement was the frequency response. Some interesting things happened.
For this basic test I used ARTA. Input and output of the card were directly connected. Therefore the results of these measurements represent the input and the output stage together. If there are any influence between both (e.g. crosstalk), this will have an impact on the measurements.
The frequency response was not very flat. The high frequency starts to roll of at 15kHz and the -3db limit was at about 17kHz – too low for 48kHz sample rate. There are also some glitches at 3kHz and 6kHz. See the frequency response below:
Is the chip really that bad? Or is there a problem with my hardware design? I did the same measurement with a Behringer UCA202. The frequency response was exactly the same. Then I wanted to see what happened to the roll-off if I decrease the sample rate. It should look even worse. But check out, what happens if you use 44.1kHz sample rate:
Much better! The roll-off starts at 19kHz, -3db is above 20kHz. No glitches anymore. What happened here? I guess, that the chip is resampling everything to 44.1kHz. I will contact Texas instruments to find out more about this behavior.
It looks like a simple task – connect the Raspberry Pi with an external ADAU1701 DSP chip. Both features an I2S interface – just connect it. However, it is not that easy. The ADAU1701 can only work as a slave device on the I2S input. Why not just using the Raspberry Pi as the master? This also won’t work, because the Raspberry Pi can create the BCLK and LRCLK signal, but not a 256xFs master clock signal that is needed by the ADAU1701. Using a local master clock on the ADAU1701 and the I2S clock from the Raspberry Pi will also not work, because both clocks have to be synchronous. Looks like a bit more complexity is needed.
We use the following setup: An external frequency generator creates the 12.288 MHz master clock and a synchronous 3.072 MHz BCLK signal. This BCLK signal will be the master clock for the I2S output of the Raspberry Pi. From this clock signal, the Raspberry Pi creates the 48 kHz LRCLK signal. Why are we not creating this clock externally? Because we have only a 2 channel signal generator available in the lab. This needs some tweaking in the sound card driver.
For measurements I use a Rigol DS2072 DSO and a Intronix Logicport Logic analyzer. That’s a lot of equipment to connect two simple devices:
I had serious trouble to get this setup running. The reason for this was a simple mistake: I switched BCLK and LRCLK. But during debugging I had another idea. The output of the ADAU1701 is an I2S master. That means it can be used also as the master clock for the input. With this setup – output BCLK and LRCLK connected to input BCLK and LRCLK, there is no need for an external clock source. The ADAU1701 can create all the necessary clocks with the onboard resonator. This will simplify our DSP project a lot.
Finally when everything worked, it looked like this on the oscilloscope: a nice analog output from the ADAU1701.
After getting I2S sound output running on the Raspberry Pi, I started communications with an ADAU1701. The chip has no sample rate converter (ASRC) integrated, therefore I had to configure the Raspberry Pi to output 48kHz I2S with BCLK=64*FS. I used the TDA1541A module, because it did exactly what I was looking for – at least at 44.1kHz.
However, when I switched to 48kHz, the I2S output changed. What happend? At 48kHz, the I2S bit clock was only 32*FS, not 64*FS anymore. It looks like a feature of the driver. This needs further investigations. I might have to create a special driver, that only enables 48kHz with BCLK=64*FS.
Update: I had a look in the driver code. Looks like there is a bug in the driver. I did a short hack to fix this temporarily, now it looks good:
Unfortunately the ADC produces only noise. I have to investigate if there is a problem with the I2S data stream or if the signal quality is to poor to interpret the data correctly.
After some work and helpful web resources, one of our Raspberry Pi’s is now generating I2S signals.
You can see, that this is a 44.1kHz playback, the LRCLK frequency is 44.17kHz, the bit clock frequency is 2.778MHz which is about 64x LRCLK (almost, the frequency counter on the oscilloscope is not extremely accurate).
Having a look at the signal curves, you can see that there is a lot of noise and ringing on the signals. However, this is no problem, the voltages are never in the forbidden area.
Another interesting question is: How much jitter do we see on both clock signals? Using the statistics functions on the oscilloscope (which are not the best method to measure jitter) we see a jitter on the clock signal of about 800 ps. On the lower frequency LRCLK, the jitter can’t be measured with my oscilloscope anymore. It is too low – which is a good sign for a high quality sound reproduction.
Many thanks to Koalo and Noise if good for the helpful guide to compile a new kernel with I2S support.
Are you looking for a Raspberry Pi I2S sound interface? Check out our HiFiBerry Mini!
You can buy 1Gsamples/s oscilloscopes now for a few hundred euros. But there are also entry-level scopes available in the range of 800-1000€. Does it make sense to invest in the more expensive devices? Check out this comparison of two Rigol devices:
There is another interesting thing about the Rigol DS2000 series featured in this video: there is a key generator out that allows you to use the features of the expensive devices even with the base device. All features are enabled and disabled just by software. Is it legal? We don’t know? But a more interesting question is: What will Rigol do about it? My guess is, that Rigol is aware of the issue and is happy about it. It’s great marketing: Sell the same product at different price points depending on the willingness to pay.
Due to the design, the LoudSnail should be almost resistant against resonances. Therefore it was interesting to see how good it really works. Due to some problems in the measurement setup and the prototyping setup, there are some flaws in the measurements. However it is already possible to see effects of damping.
Let’s start with the free-air mode:
There is a small resonance at about 2kHz, everything als looks nice.
Now put this driver in the LoadSnail housing:
Hmm, that doesn’t look optimal. There are resonances at about 400 and 550Hz. It is interesting to see, that this corresponds to 83cm and 62cm wavelengths. The snail housing itself is much smaller.
Lets put a small piece of damping in the housing:
Looks already better, but not perfect. Should we try more damping?
Looks even better. There is much more space for more damping, but I want to keep the amount minimal.
Do these resonances in the impedance graph have any impact on the sound quality? I don’t know yet, because the speaker is not ready yet. There is still a lot of work to do. More measurements will come (but not in the next days). Stay tuned!
Do you develop audio equipment – amplifiers, preamplifiers, loudspeakers? Then you know that one of the most annoying things is the cabling of the different components: sound card, preamplifier, power amplifier, speaker and computer. There are some circuits on the internet that specializes in specific measurements. But now I found a project that created a universal measurement box for all kinds of audio measurements. Check out the project at Moxtone.com. Unfortunately no PCBs are available and the microphone input is only unsymmetrical. However, the block schema gives you a good overview to build something similar. I’m already thinking about a project that combines the whole stuff on a single PCB.