Electronics > Projects, Designs, and Technical Stuff
USB noise or ground loop?
ogden:
--- Quote from: Nominal Animal on March 28, 2019, 02:54:53 pm ---
--- Quote from: ogden on March 26, 2019, 09:12:08 am ---Digital audio receivers recover clock from incoming stream and DAC usually is made as clock slave to the receiver.
--- End quote ---
That particular chip is pretty funky, and requires a 8 to 37 MHz master clock. I imagine it is very nontrivial to try and sync that frequency master clock from a 44.1 kHz to 192 kHz signal, with minimal jitter and wander.
--- End quote ---
It is not like that. Fact that you can't understand how they do it, does not mean that they don't :) Receiver does not sync to sample rate but SPDIF/TOSLINK/AES3 biphase clock which is much faster. Using VCO with PLL one can recover original clock of digital interface pretty damn well. Further reading: http://www.ti.com/product/DIR9001.
Nominal Animal:
--- Quote from: ogden on March 28, 2019, 05:27:19 pm ---
--- Quote from: Nominal Animal on March 28, 2019, 02:54:53 pm ---
--- Quote from: ogden on March 26, 2019, 09:12:08 am ---Digital audio receivers recover clock from incoming stream and DAC usually is made as clock slave to the receiver.
--- End quote ---
That particular chip is pretty funky, and requires a 8 to 37 MHz master clock. I imagine it is very nontrivial to try and sync that frequency master clock from a 44.1 kHz to 192 kHz signal, with minimal jitter and wander.
--- End quote ---
It is not like that.
--- End quote ---
You completely missed my point. You might wish to disengage strutting mode, too.
If you sync to the SPDIF clock like that, you regenerate the source clock wander. Essentially, your DAC will have the same timing characteristics as whatever the cheap PC SPDIF hardware has.
The hard part is how to adjust the high-frequency clock, balancing between the sample buffer depth and latency, without audible effects.
This is exactly the same problem as clock synchronization across domains, for example when NTP is used.
Simple algorithms and implementations are suspect to oscillation (around the proper clock rate), especially when the SPDIF clock is not very stable. UARTs avoid the problem by using stop bit(s) for resynchronization. In audio, that would lead to audible issues; changes in pitch are noticeable.
--- Quote from: ogden on March 28, 2019, 05:27:19 pm ---Receiver does not sync to sample rate but SPDIF/TOSLINK/AES3 biphase clock which is much faster.
--- End quote ---
Right. Unfortunately, it does not make the hard problem any easier, since there is no quarantee that the SPDIF clock is at all stable. The same problem applies to isochronous USB transfers.
ogden:
--- Quote from: Nominal Animal on March 28, 2019, 06:07:20 pm ---
--- Quote from: ogden on March 28, 2019, 05:27:19 pm ---It is not like that.
--- End quote ---
You completely missed my point.
--- End quote ---
What? :-//
You said it straight w/o any hint of hidden meaning: "it is very nontrivial to try and sync that frequency master clock from a 44.1 kHz to 192 kHz signal, with minimal jitter and wander".
--- Quote ---If you sync to the SPDIF clock like that, you regenerate the source clock wander.
--- End quote ---
Sure. So what? We do not talk about jitter/wander cleaning. Origial question was: is it so that TOSLINK jittrer/wander specs are as good as USB interface. Answer: it is.
--- Quote ---
--- Quote from: ogden on March 28, 2019, 05:27:19 pm ---Receiver does not sync to sample rate but SPDIF/TOSLINK/AES3 biphase clock which is much faster.
--- End quote ---
Right. Unfortunately, it does not make the hard problem any easier, since there is no quarantee that the SPDIF clock is at all stable. The same problem applies to isochronous USB transfers.
--- End quote ---
Again: so what? Unstable source clock is not a subject of discussion. Anyway even cheapest crystal oscillator solutions used in PC and it's audio devices are good enough for audio.
Bassman59:
--- Quote from: Nominal Animal on March 28, 2019, 06:07:20 pm ---The hard part is how to adjust the high-frequency clock, balancing between the sample buffer depth and latency, without audible effects.
This is exactly the same problem as clock synchronization across domains, for example when NTP is used.
Simple algorithms and implementations are suspect to oscillation (around the proper clock rate), especially when the SPDIF clock is not very stable. UARTs avoid the problem by using stop bit(s) for resynchronization. In audio, that would lead to audible issues; changes in pitch are noticeable.
... since there is no quarantee that the SPDIF clock is at all stable. The same problem applies to isochronous USB transfers.
--- End quote ---
For USB transfers, the usual solution is to do asynchronous mode transfers. This completely decouples the USB clock domain from the DAC domain. This works because the design knows the sample rate and knows how many samples are consumed by the sink in a USB frame and how many are sent in the frame, and it can control the latter using the feedback endpoint. The USB transfer rate is much greater than the sample rate, so this works and the FIFO to the DAC is never starved nor overrun. On the DAC side, a low-jitter clock is used to clock the DAC and deal with reading the data from the FIFO.
For S/PDIF where the recovered clock might have more jitter than one might wish, the usual solution is to use asynchronous sample-rate conversion with the DAC side clocked by a low-jitter oscillator.
It should be noted that strictly speaking, the S/PDIF receiver generates a sample-rate clock. The DAC needs a modulator clock, at 128, 256, 512 times the sample rate, and that clock is generated by a PLL that uses the recovered sample-rate clock as a reference. That PLL is included in the usual S/PDIF receiver chips from TI, AKM and Cirrus. That PLL output can be very good, but whether it's "good enough" depends on the application.
bloguetronica:
As others have said, most probably it is a ground loop. USB is immune to noise, since it consists of digital data transmitted through a shielded differential pair. Plus, the USB protocol allows for CRC verification of bulk transfers and subsequent correction. What happens is that you are breaking the ground loop when you switch to TOSLINK. You can achieve the same effect by disconnecting the 5V rail, presumably because you are also disconnecting the ground there and therefore you also break the loop, albeit on a different point.
You can break the loop on the USB side if you break and then reconnect the ground using two diodes in anti-parallel and a small 10nF capacitor in parallel with the diodes. This is to remedy the fact that probably, on your end device (headphones) the USB shield is probably tied to the USB ground (it should be tied only on the host side). However, there might be other factor at play here: the power supply injecting noise and facilitating a ground loop via the protective earth (your DAC is mains powered, right?).
You can see some attached schematics, to see how it is possible to break ground loops on end devices. Notice the capacitor and the resistor coupling the shield to the ground on the USB function generator. Also, on the pre-amplifier, you can see another approach that allows current going to the protective earth in case there is an isolation failure on the transformer.
Kind regards, Samuel Lourenço
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version