Tag Archives: oscilloscope

S/PDIF output transformers

Leave a reply

For the HiFiBerry Digi, we tested different methods to drive the 75Ohm output: with and without output transformers. Output transformers are not used very often in consumer SPDIF outputs: they increase the costs of a device and many people do not care about it. Bad quality transformers may even make the output worse. But for HiFiBerry Digi, we want to use them – at least as an option.

Lets’s have a look at two different transformers:

spdif-unshielded spdif-shieldedThis shows signal quality of a 192kHz S/PDIF-output. The output is simply terminated by an 75 Ohm resistor. Even the simple, unshielded transformer (left picture) works ok. The jitter is much lower than our tests with optical links. However, with the second transformer (right picture), the edges of the signal look really good. The bandwidth of the second transformer is higher.

Let’s have a closer look at the signal edge:

risetimeRise time is 2.4ns. Using the general equation for the bandwidth BW = 0.35 / Tr, we can calculate the bandwidth as about 150MHz. That’s much more than needed, but that’s good for us.

Optical SPDIF transmission and jitter

2 Replies

One argument against optical SPDIF transmission is jitter. I want to show the impact of a TOSLINK transmission line on jitter. This is a purely visual approach showing the jitter. I do not do exact jitter measurements!

The setup is as follows: A WM8804 drives an Everlight PLT/133 optical transmitter. This is connected via a 2m optical cable to a Everlight PLR/135 receiver. The SPDIF interface chip used an external 27MHz crystal as clock source.

Have a look at these two oscilloscope pictures. The first shows an audio transmission at 48kHz sample rate, the second at 192kHz sample rate .

jitter-48

jitter-192

Interesting difference – isn’t it? At 48kHz sample rate, there is almost no jitter visible, but at 192kHz, there is a lot of jitter.

This shows only, that jitter is measurable. Is it audible? Many modern DAC chips should have no problems with this kind of jitter. But it cannot be excluded, that there might be audible differences, especially on high sample rates.

Apart from the jitter there is one major advantage of an optical digital connection: there is no electrical connection between transmitter and receiver. This means, there is no risk for ground loops, which are usually a bigger problem, than jitter.

What happens, if we use a high-quality sine wave from a function generator as the input? Look at this:

jitter-siggenNo visible jitter! Why does the signal look so much better? Is it only a better signal quality created on the input? I don’t know it yet. But I suppose, that the SPDIF interface chip also has an impact on the jitter. In our tests, the 48kHz sample used an internal master clock of 256xfs, while the 192kHz test used only 128xfs for the internal master clock. Therefore it is possible, that the internal clock configuration of the chip has a major impact on jitter, even with the same external clock source (a crystal oscillator in our case).

There are a lot more questions than answers, e.g.:

  • What is the impact of jitter from the external clock source?
  • Does the internal master clock configuration have an impact on jitter?
  • How do other SPDIF sender/receiver perform?

We will look into some of these aspects in the future.

References:

  1. Wikipedia: S/PDIF
  2. Wikipedia: TOSLINK

SPDIF: 192kHz/24bit over an optical link

Leave a reply

I did some tests with the HiFiBerry Digi prototype today. As expected, everything worked without problems with 44.1/48 and 96kHz. A test with my EMU-0404 showed exactly, what I expected: no digital data could be received over the optical link at 192kHz. It’s not a problem, that’s just what the interface in this device is specified for.

Have a look at this oscilloscope picture. You see, that the signal frequency is 12.27MHz.

spdif-192

But then I did another test with the optical input of my iMac (an old model from 2009). And I was really surprise to see, that it received correct data even at the highest bit rate! That means, the receiver in this Mac is capable to receive SPDIF inputs of more than 10MHz – nice.

What are your experiences with the optical input on your DAC? I’m interested which DACs support this.

Quality of the Raspberry Pi onboard sound

2 Replies

A long time ago I had a look on the Raspberry Pi onboard sound on the oscilloscope. It looked really terrible. The sound also wasn’t good. That was the beginning of the HiFiBerry DAC development.
But how bad is the onboard sound really? How bad is it compared to our DAC?

Lets have a look on the oscilloscope. We played a 1kHz sine wave on both the onboard output and the HiFiBerry DAC. Check it out:

onboardhifiberry-sin

It is not hard to see, that the onboard sound (left) ist not really a sine wave. Why is it that way? The onboard sound is not using a real DAC, but a simple pulse-width modulation (PWM). While PWM is also used in good Class-D amplifiers (and works well there), the PWM circuit on the Raspberry Pi is trivial and not build for high fidelity sound.

Have a look at the distortions of both circuits:

thd_onboardthd_hifiberry

You clearly see, that there are much more noise and distortions on the onboard sound. The onboard-sound cannot provide high quality sound. However, we’ve seen circuits that were even worse than this one.

You want to use the Raspberry Pi for high-quality audio? Use an external sound card or our HiFiBerry DAC.

Debugging I2S audio

2 Replies

Today I spent several hours looking for a hardware problem of the HiFiBerry DAC. I had a quick look at the I2S line and the power supply – everything seemed to be ok. After some hours testing I noticed, the the sound output was working with FLAC files, but not with WAV files. WTF? At least it was clear now, that I should look for a software problem, not a hardware problem.

Here is a picture of the BCLK and LRCLK lines when playing back the FLAC file:
i2s-32

And this is the playback of the WAV file:
i2s-20

Can you see the difference? In the second scope picture you can see, that the driver only creates 20 clock cycles for the left and the right channel, in the first case  there are 32. Because the DAC supports only BCLK=64xLRCLK, it does not create any output in the second example.

Therefore, when debugging I2S circuits, not only have a look if there is a signal on all lines, but also check, that the clock frequencies are correct.

The first signal generated from our DSP board

2 Replies

After some hours of debugging and fixing a hardware problem, the DSP hardware seems to work now.

hifiberry-dsp-soldered

There are still cables soldered for I2C debugging purposes, but writing to the DSP works without problems now. I still have to work on reading data back from the DSP. Therefore the debug cables are still soldered. You also see, that the voltage regulator at the bottom is not used yet. I will do some comparison tests with a separate voltage regulator for the analog circuit.

I created a simple DSP program that generated different waveforms on the different output. Let’s see what happens on the output:

waveforms

Looks good! The DSP now runs at 48kHz, therefore the triangle waveform is not exactly a triangle. But that’s what you would expect.

 

PCM5102 charge pump frequency

Leave a reply

The PCM5102 is a nice I2S DAC. We use it in you HiFiBerry Mini DAC. It is easy to use, because it does not need a master clock and can run on a single 3.3V power supply. To generate a full 2Vrms signal, the chip uses an internal charge pump (with two external 2.2uF capacitors) to generate a negative power supply.

Unfortunately the datasheet gives no information about the switching frequency of the charge pump. But it’s not a secret. You can simply have a look on the voltage on the external capacitor. What do we see? Switching frequency is about 850kHz – way out of the audible frequency range.

pcm5102-charge-pump

 

Update 13.11.13: It seems, that the charge pump frequency depends on the sample rate. We’ve seen even charge pump frequencies above 1MHz.

Connecting a Raspberry Pi and an ADAU1701 DSP

13 Replies

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.

The ingredients of this test setup are

  • Rigol DG4062 signal generator
  • Raspberry Pi
  • MiniDSP (our own DSP board is not ready yet)
  • Lab power supply

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:

raspberry-dsp-tests

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.
adau1701-out