How does a TOSlink to USB converter (feeding computer) reduce TOSlink jitter?

[Music1969]

Hi all

Question as per title: How does a TOSlink to USB converter (feeding computer) reduce TOSlink jitter?

Yes I mean TOSlink to USB feeding computer - not USB to TOSlink from computer.

Is it the converter that deals with the TOSlink jitter or the PC/Mac?

Before someone says there's no audible issue so don't worry - yes that's fine. I am not in a panic.

Just curious how it works

Example: recording a TOSlink source on PC/MacOS

 

[Miska]

Question as per title: How does a TOSlink to USB converter (feeding computer) reduce TOSlink jitter?

Since there is no D/A conversion involved based on the recovered clock, any jitter is not affecting the signal since the data is transferred correctly and sample rate is nominal.

Just like you would copy a file from harddisk to another one. Any clock jitter in this copy process doesn't affect the data.

 

[Lambda]

Imagine i reed some numbers to you and you write them down. Sometimes i say a number a view milliseconds earlier and sometimes a view milliseconds later (that’s) jitter.
Now you read waht you have previously written down... the jitter is gone

 

[Music1969]

Since there is no D/A conversion involved based on the recovered clock, any jitter is not affecting the signal since the data is transferred correctly and sample rate is nominal.

Just like you would copy a file from harddisk to another one. Any clock jitter in this copy process doesn't affect the data.

Thanks! Offline discussion with @MC_RME confirmed the same. Only matters in D/A and A/D conversion.

It was my misunderstanding that, say with a horrendously bad jitter TOSlink source , this jitter would be measurable in 'real-time' , even in the digital domain. The timing of the bits would be off. But now I see my thinking didn't make sense. As long as all the bits get there (bit perfect) then that's all that matters in digital domain.

When I run internet speed test app on my phone, jitter is reported, even though its all in digital domain.

So I was a bit confused.

But, what you are asking, I am looking for! Where do you find a Toslink to USB converter? I just want to get that PCM to USB so I can use a USB-C dongle DAC I prefer with some 16/44.1 (not demanding) music. It is the best DAC I own.
I kind of thought, legacy Toslink to (also) legacy USB, keeping it all PCM until conversion, would be a piece of cake and be common. Be it into a computer or a DAC.
But is like tracking down a unicorn…

I have an RME ADI-2. One of its many features that I use is TOSlink to USB conversion.

miniDSP make one too for much cheaper:

USB Audio Streaming

miniDSP's USB audio interface range from the low cost stereo interface to the complex XMOS based multichannel, Asynchronous USB audio modules doing up the 8ch @ 192kHz.

www.minidsp.com

 

[Propheticus]

When I run internet speed test app on my phone, jitter is reported, even though its all in digital domain.

That jitter is fluctuations in ping times.
Matters when you play an online shooter game where all actions/movement are shown without much delay. Or voice over IP (teams call) where too much buffering causing delays is also unwanted. Matters far less for a download, streaming a (buffered) song or video or browsing a website.

These ping time fluctuations are orders of magnitude larger (milliseconds) than digital audio signal jitter (picoseconds - nanoseconds)

 

[Miska]

When I run internet speed test app on my phone, jitter is reported, even though its all in digital domain.

That is variation of the connection speed over time. It doesn't affect data correctness. Or audio unless the speed sags so much that you'd get a drop-out.

Only thing that matters for audio is conversion clock jitter, that is at the edge of analog and digital domains. Where you can have variation between digital domain time (virtual/abstract concept) and analog domain time (real world). Where digital domain assumes time between digital samples to be some exact number of nanoseconds, but the real world clock in analog domain fluctuates from the assumed accurate value.

 

[KSTR]

Wrong direction.

It's TOSLINK Output and Input, so both directions.

 

[KSTR]

That info sure was buried and worded differently on that web site. Anyway, too expensive and wrong USB plug.

How can it be buried when you simple have to look at the product picture to get it?

OP said:

Yes I mean TOSlink to USB feeding computer - not USB to TOSlink from computer

Any USB device has an USB-B receptacle (not: plug) and it only depends on the cable which plug it has.

 

[ReaderZ]

Imagine i reed some numbers to you and you write them down. Sometimes i say a number a view milliseconds earlier and sometimes a view milliseconds later (that’s) jitter.
Now you read waht you have previously written down... the jitter is gone

So why not a buffer on receiving side to remove it all the time?

 

[Lambda]

So why not a buffer on receiving side to remove it all the time?

This is what happens in a PC receiving digital data.

 

[ReaderZ]

This is what happens in a PC receiving digital data.

Yes, but why not on all DACs if that would eliminate all jitters.

 

[ebslo]

Yes, but why not on all DACs if that would eliminate all jitters.

DAC's have to play the stream in real-time, so it doesn't work. Consider the following:
* The DAC takes the samples as they come in from the TOSLink, as clocked by the source, and puts them in a buffer.
* After the buffer has some number of samples in it, the DAC starts playing samples from the buffer on it's own clock.
* Since the TOSLink source clock runs at a slightly different rate than the DAC internal clock, the sample buffer eventually either under-runs or over-runs depending on whether the DAC clock is slightly faster or slightly slower than the source clock.

So instead, good DAC's filter the source clock with a PLL which produces a clock with most of the jitter removed yet, when measured over a long period of time, has exactly the same frequency as the source clock.

The only other option would be to re-sample the data, but doing so would require a DLL to generate a filtered representation of the error of the source clock relative to the local clock, which would likely have similar jitter-rejection characteristics as the PLL in the technique above.

 

[antcollinet]

Yes, but why not on all DACs if that would eliminate all jitters.

That is exactly what (modern - this century) dacs pretty much all do.

The incoming data is buffered, and a local clock is generated using a phase locked loop. Jitter is pretty much eliminated - at least down to inaudible levels.

This is why all the nonsence about different usb/optical/coax cables influencing sound is.... nonsense.