DigiOne RCA/BNC output for RPI

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Timing miss registrations...are you talking about i2s bus ?

If you are... you are forgetting the master clock is the one realigning...the same MCLK that commands i2s data is also realigning . Jitter of mclk = spidif jitter .

Can we bet on it ?

The Mclk CANNOT "re-align" the signal with a simple flip-flop. All you are doing is creating a new transition based on the Mclk. But if the data bit starts early, you are then moving the transition further into the bit period. Likewise if the data is late referenced to the new clock, you are inserting a new transition too early. In extreme cases you can see where this could miss the bit window completly.

In order to remove or minimize jitter one must use a FIFO buffer so the re-clock can be truly aligned with the rough edge of the existing data transitions. And the re-clock must also be referenced to the data stream via a LPF and that's what removes or minimizes the jitter. The jitter performance is that of the LPF response. Yes, it's still a very much an analog world out there.

Now in your application, none of this really matters because the stream from the RPI is probably very stable to begin with. But along those lines, how are you synchronizing you onboard Mclk with the RPI ckl? Or are you using your Mclk to drive the RPI? In either case the two clocks must be phase aligned and locked.
 
Remember... this is used with a pi in master mode, the MCLK (and other i2s lines) simultaneously go into the pi aligning the PCM data from the beginning (it *is* the alignment.) Isn't that a perfect reference to then reclock it right at the output (again using the same MCLK)?

*so my understanding is it's one physical MCLK driving pi PCM data, wm880x, and Ioan's final decoupled flip-flop output simulaneously.
 
Last edited:
Remember... this is used with a pi in master mode, the MCLK (and other i2s lines) simultaneously go into the pi aligning the PCM data from the beginning (it *is* the alignment.) Isn't that a perfect reference to then reclock it right at the output (again using the same MCLK)?

*so my understanding is it's one physical MCLK driving pi PCM data, wm880x, and Ioan's final decoupled flip-flop output simulaneously.


Correct. I feel that my mastering of the english language is lacking the precise math language of what I understand.

An audio digital rendition of an analog signal its easy. You have DATA that is actually a point in a wave taken at 44Khz for example (44.000 samples per second)...meaning that you sample points at EXACT clocks/units of time.

In spidif you have the same DATA (with embedded extra clocks x2 so the slave can have extract MCLK)

If you can send this spidif DATA without jitter, the slave will extract the analog at exactly the point where it was sampled .

In our DigiOne stream is sent reclocked with the same MCLK as DATA (original DATA)

For me, it stands to reason that extracted analog will be an exact copy (with a jitter of 0.5ps) of original points

And yes Scott , the same MCLK is used for DATA , embedding clock on spidif and final re clocking of each individual clock on SPIDIF stream.

For me its very clear there are no mistakes and final jitter is 0.5ps (basically light travels 15mm in that period..)

Yes DigiOne is that good.

Gusser do you have a good DAC with SPIDIF/BNC/Coaxial input ?

At last some of your resoning seems to be meta stability. We took care of it...we actually use multiple flip flops to mitigate it. We seen this problem before on Kali.
 
Last edited:
Remember... this is used with a pi in master mode, the MCLK (and other i2s lines) simultaneously go into the pi aligning the PCM data from the beginning (it *is* the alignment.) Isn't that a perfect reference to then reclock it right at the output (again using the same MCLK)?

*so my understanding is it's one physical MCLK driving pi PCM data, wm880x, and Ioan's final decoupled flip-flop output simulaneously.

But if it's that good, and I agree it is, then why the need for re-clocking? Surely there isn't going to be any significant jitter induced with the inch or two of wiring?

I just feel this is a solution looking for a problem to solve.
 
Correct. I feel that my mastering of the english language is lacking the precise math language of what I understand.

An audio digital rendition of an analog signal its easy. You have DATA that is actually a point in a wave taken at 44Khz for example (44.000 samples per second)...meaning that you sample points at EXACT clocks/units of time.

In spidif you have the same DATA (with embedded extra clocks x2 so the slave can have extract MCLK)

If you can send this spidif DATA without jitter, the slave will extract the analog at exactly the point where it was sampled .

In our DigiOne stream is sent reclocked with the same MCLK as DATA (original DATA)

For me, it stands to reason that extracted analog will be an exact copy (with a jitter of 0.5ps) of original points

And yes Scott , the same MCLK is used for DATA , embedding clock on spidif and final re clocking of each individual clock on SPIDIF stream.

For me its very clear there are no mistakes and final jitter is 0.5ps (basically light travels 15mm in that period..)

Yes DigiOne is that good.

Gusser do you have a good DAC with SPIDIF/BNC/Coaxial input ?

At last some of your resoning seems to be meta stability. We took care of it...we actually use multiple flip flops to mitigate it. We seen this problem before on Kali.

Yes, personally I use Lucid DACS. 24 channels worth in my HT system. These are recording studio grade units. I use 110ohm AES which is the same as data stream as SPDIF with exception to the channel status bits but otherwise fully compatible with SPDIF via simple impedance and voltage conversion - an RF transformer.

I also have designed HDSDI interfaces at 3gbs. Here things like jitter really matter and we even resort to NRZI scrambling to preserve the clock duty cycle. No need for that on AES or SPDIF, simple Manchester encoding works fine. Engineers who design 10GB+ Ethernet switches and interfaces face similar design issues these days.

Based on sending the RPI a stable clock source, I fail to see the need for re-clocking on the SPDIF output. The raw SPDIF out should be well, well, within jitter specifications.

BTW, SPDIF and AES is more than just the clocked audio data. There are control bits as well as an optional CRC over a period of several words. Making SPDIF is not a simple as adding clocks to the raw audio data. Fortunately there are many chips and FPGA libraries that do this function as a black box.
 
Last edited:
Yeap you are right there are also control bits...but they also x2 bclk speed.

We had a choice when designing :

1. WM8805 is a master using 22/24Mhz clocks . It can then send a SPIDIF output .Whiteout directly measuring we know most silicon have 50ps of jitter (minimum) Also you need to think about galvanic isolation at output and only choice is a transformer that will distort the signal..

2. WM8805 as a master ...same spidif stream . However this time we can reclock it with a KNOWN jitters value (mclk) on a silicon (flip flops) that was made for that specific purpose. Also galvanic isolation can happen (in this case only) after the rpi/wm8805...so a pure ground.

Attached the signal output at BNC.
 

Attachments

  • spdif_BNC (002).pdf
    833.3 KB · Views: 157
Hi. Just received my Digione. Thanks for that!
Just one minor detail... I can't get it to work.

I tried the special Volumio distro and the dietpi distro with Roon endpoint. Neither work. Only Volumio displayed a status for the Alsa mixer: no such hardware found...

Digione displays a green power led.
Setup is raspberry3, digione. Raspberry powered by 2A switchmode power supply.

What can I do? Or is my device faulty?
 
Last edited:
Hi Jeff

I would sugest the fallowing :

Remove and reinsert the digione. Sometimes the RPI connector has problems.

Check your SD card. Try a new card and flash it.

We test each card before shipping, however it does not mean it cannot be faulty. Usualy we find that the 2 steps above will solve most problems.

(and make sure your smps is 2A. Was it working before with your RPI3 + DAC ?)Are you using a WIFI on it that might increase the power requirements ?
 
Hi cdsgames,
I am having the same issues as Jefferyd above with my new digione.
Im using the latest version of picoreplayer 3.21 with the integrated digione drivers, but squeezelite refuses to run.
Have also tried the special version of volumio and get 'status for Alsa mix no such hardware found.
Its looking like my device is faulty, how do I go about getting a replacement?
Thanks
 
The digiONE's peeking out. Surprised there's not more talk about it on this thread...!

2f8TOUI


Really simply a reference spdif source for me so far, no need to even worry about it, wonderful musical sound. Working on a whiteup and some comparisons... might play around with power a bit. Used a ciaudio power supply thru the pi GPIO 5V from the start. piCorePlayer/rambuffer/gigabitUsb/BNC-BNC cable setup.
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.