iago

The 1ps value is the jitter equivalent for the oscillator chip. Through dividing the clock and processing audio signals this value will rise. I have seen estimations that the complete device has intrinsic jitter of around 50ps. External frequency standards use 10 MHz frequency, which makes wave length approximately 20m (assuming c/c0 = 0.7). Half a meter of transmission line would not have a significant impact on the oscillator signal - if you take proper care of the quality of the connection, as *progear stated (cable impedance, connectors, termination). While accuracy [1] and stability [2] play a role in usual clock applications, phase noise is probably more relevant for use of a clock source in audio, and here especially the phase noise distribution. The absolute height of the "noise floor" (which has the greatest influence on the one-dimensional jitter value) is of less importance than the area of least offset from the oscillator frequency (left margin of diagrams below). Differences in noise distribution might explain why external clock sources can bring an improvement over the internal one. Actual phase noise diagram (source: Temex) and theoretical noise distribution (source: Analog Devices) [1] Deviation of the sample clock's frequency from the nominal value, usually expressed as quotient of the clock frequency (df/f) [2] Long term drift (ageing) of the clock's output signal, also expressed as df/f

Very interesting product, and I would be really interested in a comparison between Sonicorbiter's and other device's sonic qualities ...

Throw out the VLink, it's performance is rather mediocre. Mutec or Berkeley between Server and DAC will make a very noticeable difference (I once owned VLink II). All subsequent DAC changes will be more subtle. The impact of a dedicated USB card will be much less if you have a re-clocking device like Mutec in between than if you feed directly into a DAC.

Digital circuits need clocks, that is what makes them tick. In a perfect world you would need exactly one clock source. As near as possible to the digital-to-analogue conversion, and derive all other clock signals from here. In a less perfect world, each circuit would have its own clock, with the next in line slaving to it. This is where re-clockers like REGEN come in: they help to overcome imperfections in the upstream clock circuitry. Possibly you could do without REGEN, if your source signal is good enough. Also on the DAC side, devices which rely on the recovered clock from the incoming signal profit more from improving the signal quality than devices which have sophisticated internal clock recovery features. Thus, as always, it depends ...

I believe vdgraaf's system is already optimized, and not running standard Windows. I prefer Linux myself, and run a custom embedded image on my music server (including mpd). I found x86 based systems easier to integrate than ARM based ones [1]; also I'm mainly looking for 64-bit systems, and these are the reasons why I got interested in these Z3735 based devices. [1] usually with ARM based hardware you are forced to use out-of-tree kernels, which makes integrating the RT patch quite painful

You might try a supply with linear regulation, if you have the chance. I usually find it clears up the stage representation a little. Before acquiring aforementioned box I was also looking at these stick type devices (hardware is comparable), but was not sure if they work without being "stuck" somewhere. Thank you for confirming that they work solo.

So these "sticks" work without the HDMI connection? That is good to know. I recently acquired one of the Z37 based boxes to see if I am able to port my music server to it, but have not made much progress yet. How do you power yours? With the usual USB charger?

Dynamic range in this case seems to be the difference between 'Minimum RMS Amplitude' and 'Maximum RMS Amplitude', which is closer to the normal use of this concept in engineering. I believe 'Average RMS Amplitude' in your examples seems to be a better indicator of compression used during recording.

The Orbital Research was configured for 50R termination, just as the Temex is. It was part of a package that I had the chance to evaluate in my system some while back. A 50R clock source is not compatible with the Mutec's input, this is why the Mutec MC-3+ had the option to remove internal termination and replace it with external one. I find no mention thereof in the MC-3+USB manual. The difference between proper termination and 50 into 75 Ohm was not great with Temex and MC-3+; but this seems to be very much source and destination dependent. I use a Hameg HM7042 to power various components that expect to be supplied by DC. It may not be audiophile, but it is incredibly fast and protected electronics from user errors in the past :-) The whole package? The POS based solution (in a proper case with its own power supply) would have cost 1000 €, my current solution (looks more like a laboratory setup) was 100 $ for clock source, the power supply was already present. If you build your own from available components (clock module, power supply, case, various connectors) you should calculate something between 1000 $ (excluding sales tax) and 1000 € (including sales tax).

Hi SwissBear, the improvement is something I am still evaluating ;-) With MC-3+ it was definitely there, with MC-3+USB I'm still struggling to pin-point differences between 'naked' USB-to-S/PDIF, re-clocked conversion and external reference. I think I will have to get used to the new device (some may call it burn-in) before I can make a more conclusive statement. The clock is a TEMEX LPFRS-01 salvaged from an old telco installation; I bought it second hand on ebay some years ago. The performance of this clock source is OK, but not up to modern standards. I had the chance to test Orbital Research POS some time ago, it was slightly better, but the improvement (for me, in my system) was not enough to justify the expenditure. For a new solution I would currently consider Rakon ROX3827T3.

Thank you SwissBear and gldgate for responding, and sorry if I created more confusion by asking. I was comparing settings between MC-3+ and MC-3+USB, which have changed slightly. Both MC-3+ operate with or without reclocking, which seems to be selected via the MODE switch; only in MC-3+ only one option is lit at one time, in MC-3+USB either one or two options can be selected. I was wondering about the difference. Clock reference source is still selectable via the REFERENCE setting. I believe you can tell if MC-3+USB is in re-clock mode by the STATUS LEDs: if the device is in re-clock mode, two of the status lock LEDs are lit (input PLL, output PLL?), otherwise one. Here are my current settings for reference. Please note that I am running the devices with external clock reference. MC-3+ settings MC-3+USB settings

Another question for Julian (enjoy your holiday, by the way): What is the interaction of the different MODE settings with the MC-3+USB's performance? The manual I received is a bit vague on that matter. There seem to be three distinct settings: (1) INTERN (2) INTERN + RE-CLK (3) EXTERN + RE-CLK While I can understand what (2) and (3) are accomplishing (they correspond to MC-3+ (without the USB) functionality) -- what is the difference between (1) and (2)?

I just checked my power supply: additional power consumption with Mutec plugged in is approximately 2W, which should correspond to a current draw of 0,35A from the device.

I have experienced this phenomenon with some releases myself. The content of the disk(s) seems to be slightly different than the normal releases, thus they are not found in the accuraterip database. I'm using EAC, and the report usually is "cannot be verified as accurate". If the two check sums from the test run and the rip match, I do not worry about it. If the checksums are different, it's usually caused by a bad rip; in that case the ripping program will have reported a lot of errors [1] during processing the disk. In that case I clean the disk (since yours is practically new this is unnecessary) and rip with reduced speed (as much reduced as the disk drive allows) - in 50% of the cases this produces a rip without errors. Track 1 Filename Z:\media\temp\music\The Brandos\Honor Among Thieves\01 Gettysburg.wav Pre-gap length 0:00:02.00 Peak level 89.9 % Track quality 100.0 % Test CRC DD5BE5BD Copy CRC DD5BE5BD Cannot be verified as accurate (confidence 9) [3B54B23A], AccurateRip returned [FF2207B2] Copy OK I use a mild polish as used in restoring high-gloss paint only if really bad scratches can be identified to cause rip errors. Sometimes the result after polishing is worse than the original :-) [1] EAC shows a CR2 counter which increments during the rip, also the drive speed will be reduced greatly due to multiple retries

Ubuntu uses a sound server called PulseAudio for connection to the audio interface. With PulseAudio in place, you have the same issue as within Mac OS/X, you have to switch sample rates whenever you want to playback a different one. The default configuration is 48 kHz and PulseAudio will resample everything to that sample rate, using a rather lossy internal algorithm. This may be the effect you are hearing. To check, play some music directly using ALSA tools and observe if it sounds closer to what you are used to: aplay -l # check audio devices flac -cd "path/to/a/flac/file" | aplay -D "hw:1,0" # replace hw:1,0 with correct address If you want to avoid changing the sample rate every time you play back a different source material, you could use a player that directly links to the ALSA driver and uses the output exclusively. It will then adapt the sample rate automatically. Players that support this feature are, for example, Audacious, Clementine Deadbeef, and mpd.