Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[waiting4windshield]

When listening to music, I sit with my laptop a few meters from my equipment rack. My rack is where I keep a powered USB hub with a connected USB flash drive and a connected DAC, where the DAC has both USB and S/PDIF digital inputs. The laptop runs MC33 and is itself connected to the powered USB hub via a 3m USB cable.

Specifically:

The 2TB flash drive [containing FLAC and DSF music files] is connected to the powered USB hub via a short USB-A-to-USB-C cable -- i.e. USB-A at the hub.

Using the Benchmark DAC3-B's USB 2.0 digital input, the DAC is connected to this same powered USB hub via a short USB-A-to-USB-B (printer) cable -- i.e. USB-A at the hub.

The 64-bit Windows-10 laptop is connected to this same powered USB hub via a 3m (i.e. long, but within spec) USB-A-to-USB-B (printer) cable -- i.e. USB-A at the laptop.

For MC33.0.72 [running on the Windows-10 laptop] to perform its various DSP and DSD-over-PCM (DoP) functions. the audio data must necessarily be transferred from the flash drive to the laptop via the USB hub and the 3m USB cable. After processing by MC33, the audio data must be passed to the DAC3-B via the 3m USB cable and the USB hub.

This configuration seems unlikely to deliver optimal sound quality from the DAC3-B's USB input. In particular, I suspect that the 3m cable introduces jitter, and I find that the DAC sounds much better when I employ the DAC's S/PDIF coaxial input. i.e. Instead of USB to the DAC (from the USB hub) I employ a USB-to-SPDIF converter at the USB hub -- which effectively reclocks the digital signal -- followed by a short digital coaxial cable to the DAC's S/PDIF input.

Can anyone confirm that a long USB cable would degrade the digital data output from MC33 running on a Windows-10 laptop? [I recently applied a Windows-10 Update which may also have had an effect on sound quality.]

Short of running MC33 in client/server mode to eliminate the 3m USB cable from the data path, is my use of the DAC's S/PDIF input (and reclocking of MC33's output) optimal?

Is there a mechanism whereby MC33 can preprocess the audio data and save that data to disk? (In this way, I would hope to bypass MC33 on playback by having the DAC pull the audio data directly from a co-located disk over a USB i/f.]

[mwillems]

So I think it's unlikely that USB cable length (at least when measured in single digit meters) has any meaningful effect on jitter with a well-behaved DAC.  SPDIF, if anything, is more prone to induce jitter than USB because the audio and clock information are transmitted in the same serial transmission.  A good DAC with an asynchronous USB input (which I believe the Benchmark has) should have irrelevant quantities of jitter regardless of USB cable length because the timing is controlled by the DAC not by the input stream.

If you're concerned, you can always measure the output and see for yourself.

[waiting4windshield]

@mwillems - Thanks for your feedback.

More than a few people have opined that they believe that the Benchmark DAC3's sound via that DAC's S/PDIF inputs betters that DAC's sound via its USB input:

• https://www.thomannmusic.com/benchmark_dac3_l_black.htm
• https://audiophilestyle.com/forums/topic/61748-benchmark-dac3-vs-%E2%80%98higher-end%E2%80%99-dacs/
• and now me

That said, I just reconfigured my setup to (again) use the Benchmark DAC3-B's USB input and now I hear no SQ degradation vs the DAC's S/PDIF input. I have no useful explanation; I'm glad it works (again).