Electronics > Projects, Designs, and Technical Stuff

USB noise or ground loop?

<< < (5/6) > >>

Nominal Animal:

--- Quote from: ogden on March 28, 2019, 07:02:43 pm ---So what? We do not talk about jitter/wander cleaning.
--- End quote ---
Reading difficulties, eh?


--- Quote from: drummerdimitri on March 24, 2019, 02:27:55 pm ---The only reason I slightly prefer to use USB is for its supposedly lower jitter specifications and asynchronous clock.
--- End quote ---

Nevermind; one more to the ignore list.

ogden:

--- Quote from: Nominal Animal on March 29, 2019, 06:41:35 pm ---
--- Quote from: ogden on March 28, 2019, 07:02:43 pm ---So what? We do not talk about jitter/wander cleaning.
--- End quote ---
Reading difficulties, eh?

--- End quote ---

Did I miss where OP asked for jitter/wander cleaning? Please be so kind and remind me.

Oh, this?


--- Quote from: Nominal Animal on March 29, 2019, 06:41:35 pm ---
--- Quote from: drummerdimitri on March 24, 2019, 02:27:55 pm ---The only reason I slightly prefer to use USB is for its supposedly lower jitter specifications and asynchronous clock.
--- End quote ---

Nevermind; one more to the ignore list.

--- End quote ---

LOL  :-DD

It is


--- Quote from: ogden on March 28, 2019, 07:02:43 pm ---Origial question was: is it so that TOSLINK jittrer/wander specs are as good as USB interface. Answer: it is.

--- End quote ---

And not jitter cleaning, you  |O

Nominal Animal:

--- Quote from: Bassman59 on March 28, 2019, 08:02:13 pm ---For USB transfers, the usual solution is to do asynchronous mode transfers.
--- End quote ---
I know; I didn't even realize USB Audio uses isochronous transfers.

Similar issues do occur elsewhere, too.  One is when you have more than one DAQ (because you are measuring many things at once), at high sample rates, and you want to synchronize the data.  I am not at all familiar with USB audio, but I do have experience on the software side on similar issues. OP mentioned jitter, and that made me think about how I would solve the clock discrepancies, based on my experience in the software side with sensor data.


--- Quote from: Bassman59 on March 28, 2019, 08:02:13 pm ---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.
--- End quote ---
VLC (the video player) has a feature that allows one to resample audio to the achieved display frame rate.  It is surprising how small changes in the actual pitch are perceptible -- in that case, because the video frame rate was not stable, so the resampling ended up changing the audio pitch by accident.  It is a surprisingly easy to notice very small changes, if the display frame rate is not rock solid stable.


--- Quote from: Bassman59 on March 28, 2019, 08:02:13 pm ---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.
--- End quote ---
I would assume a separately controlled high-frequency clock, compared to the SPDIF clock, would yield a much better result from not-very-good-quality SPDIF sources.

Algorithmically, the idea is to decouple the generated clock from the original clock source, but control it to run stably at the average rate of the original source.  This kind of synchronization issue is surprisingly common in high data rate networked computation.  Mathematically, you can describe the follower as a damped oscillator -- which is a pretty good description of a PLL based on the SPDIF clock --, but unless you deliberately add some latency, maybe just a few dozen samples worth, there always will be patterns that lead the follower to oscillate.  In the algorithmic sense, it is very interesting and surprisingly difficult problem; and from the benefits of that latency (or "temporal slop"), I know that a PLL cannot be the best option here.

Adjusting properties according to human perception, or psychoacoustic modeling in this case, is very interesting.  Many people do not realize that even MP3 compression involves psychoacoustic modeling: the quantization noise is shaped to follow the equal-loudness contour.

ogden:

--- Quote from: Nominal Animal on March 29, 2019, 07:08:43 pm ---
--- Quote from: Bassman59 on March 28, 2019, 08:02:13 pm ---For USB transfers, the usual solution is to do asynchronous mode transfers.
--- End quote ---
I know; I didn't even realize USB Audio uses isochronous transfers.

--- End quote ---

Apparently you do not know. Next time before explaining how stuff works, make sure you understand subject well. Especially embarrassing is to start "for those who do not understand..." and provide BS (about USB audio) in explanation:


--- Quote from: Nominal Animal on March 24, 2019, 03:34:58 pm ---For those who do not understand the difference, SPDIF/TOSLINK is one-directional.  The computer will send a digital audio signal at a fixed frequency, and the DAC simply has to try to keep in sync.  For say 48000 kHz audio sample rate, if the computer and DAC clock differ by just 1 Hz or 0.002%, each second there is either an extra sample, or a sample is missing.  That is what jitter is; timing error.  The DAC cannot just buffer the data, because there is no way for it to signal back to the computer that it needs more data (DAC clock is fast compared to computer) or that the computer should wait for it to play it back first (DAC clock is slow compared to computer).

With USB data, the audio signal is transferred in short blocks (up to 1023 data bytes for full-speed USB, 12 Mbit/s), with header and checksum data (typically the overhead is less than 25%). Each successfully sent data block is acknowledged.  Essentially, the computer does not need to have an internal clock, and provides the data asynchronously to the DAC; it simply sends audio data whenever the DAC is ready for it.

--- End quote ---

bloguetronica:
I'm noticing some confusion here between asynchronous USB transfers, that don't exist, and isochronous transfers. As far USB is concerned, there are two types of transfers for massive data: bulk and isochonous. Both have CRC verification, but only bulk guarantees correction (i.e.: data is delivered, if not, rinse and repeat until it is). Other types of transfer exist for control and signaling: control and interrupt transfers. Hope this little bit of information is useful.

Just a tidbit regarding my previous post. It didn't occurred to me that audio uses isochronous transfers, and I should have known better. Still, what I've said is pretty much right. In a nutshell, USB noise will not translate to noise in audio, but in lost packets, and that is the absolute worst case. USB communication is very stable and you would need something like an EMP generator to corrupt it. The OP is experimenting the symptom of a ground loop.

Having said that, there is no need to perpetuate the snake oil myth that USB needs "filtering" or needs to be "improved" in a audiophilic (say more audiophobic) way, or in any other way. The engineers that developed the USB protocol know better, much better when asleep, than the audiophiles that came up with the idea of "improving" the USB by creating "audio-grade filters".

Kind regards, Samuel Lourenço

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod