Schiit EITR

[zalive]

Hi.

 

Does anyone know if Schiit has ever given out specification info about Eitr rise time duration (for signal transition)?
This is a good parameter to know for the sake of planning of S/PDIF cable length.

 

Audiophileo2 for example specifies vey short rise time (<1 ns), which is great because it guarantees signal transition will be over before signal reflection arrives back to DAC coax input, so it won't introduce jitter related to transmission - because of this coax cable length won't matter, so short cables are great to use.

 

However, typical rise times are said to be much longer, something like 25 ns? In which case cable lenght will likely make a difference as jitter is concerned, so it may pay off to use long enough cable...

 

Anyone experimented with longer lengths S/PDIF coax with Eitr like 1.5, 2 or 3 m?

[zalive]

On 11. 01. 2018. at 8:44 AM, nbpf said:

On another track: I am still trying to understand why the Eitr is now almost indistinguishable (and sounds perhaps a little bit worse) than my trusted M2Tech hiFace Evo. Three weeks ago, when I first put the Eitr in my system, I had the impression that it sounded distinctly better or, at least, different than the M2Tech. Is your Eitr on 7/24? Have you noticed any variation of the Eitr's sound quality in time? 

 

S/PDIF transmission can become a bottleneck, as I understand. USB to S/PDIF converter with precise reclocking, good galvanic isolation and quality power supply can do wonders in supplying quality digital stream with low jitter and noise, however, S/PDIF transmission itself can introduce much more jitter than converter itself because of the influence of signal reflections. 

 

Another point, Hiface Evo (the first one) is AFAIK one of rare USB audio devices with implemented USB bulk mode asynchronous transfer, which is pretty much insensitive to USB cable used when it comes to the biggest issue related to USB asynchronous isochronous transfer (which is used in UAC1 and UAC2). Isochronous USB transfer is not bit-perfect because there's no packet resend implemented - there is CRC check but nothing is done when CRC is not ok. No error correction, no packet resend. So with UAC1/UAC2 devices actually a good USB cable matters to introduce less bit transfer imperfections. Standard USB computer cables may be sufficient for bulk mode used to transfer data (resend used whenever needed to ensure bit perfect transmission) are not so good for UAC1/UAC2 asynchronous isochronous transmission. 

 

Since I started my DAC story with USB DAC devices, I have some experience from the past, unlike with S/PDIF - Eitr is my first experience with it. From the past I have two quality USB cables which I can recommend: Cardas Clear USB and Audioquest Coffee. The first does wonderful job with the low end, the second one is bit more resolute at the high end (but also more expensive, too). On the other hand, cost effective solution is Supra USB according to my experience. It's not as refined in highs, but it still gets majority of the job done in a good way. 

 

As for sound change of Eitr, it might be run in changing the sound. In many cases I experienced various equipment open up highs after run in, in some cases the sound without run in was better because of better balance. 

[zalive]

2 hours ago, nbpf said:

Thanks for the very interesting analysis and conjectures. I was not aware of the fact the the old M2Tech hiFace Evo uses a protocol that supports error correction, this raises the question of why modern USB to S/PDIF interfaces rely on protocols that are potentially not bit perfect.

 

My current conjecture for explaining the somehow puzzling results is that I am using a DAC (the old Naim DAC) that anyway overrides the clocking of the S/PDIF stream with its internal clocks. Thus, the different clocks of Eitr and M2Tech might in fact have no impact on the sound quality and all what I hear are differences in noise levels. Since both the Eitr and the M2Tech provide rather good isolation, it is conceivable that they sound almost the same. This conjecture, however, does not explain the differences that I have heard between the Eitr and the Mutec MC-3+ USB. 

 

By the way, I am using a Naim DC-1 1,2m cable both for the Eitr (via Canare RCA to BNC adapter) and for the M2Tech. I have tried a 0.7m Supra RCA-RCA cable between the Eitr and the DAC (the Naim DAC has two BNC and two RCA inputs) with almost identical results. 

 

Well UAC protocols ensure them easy compatibilty with any system that supports it, a generic driver should do the job whenever they're fully compliant to UAC1 or UAC2. With USB bulk mode you need fully propriatery drivers. Besides, you need much more buffering as bulk mode is said to have a lower priority than isochronous and doesn't guarantee bandwidth at any given mode.

 

I still believe it should be superior to UAC1/UAC2 with a good implementation and a reasonably good computer transport system, though.

 

As for Naim well it might depend on implementation...I wonder if Naim first uses encoded S/PDIF clock signal for conversion, then its own clock to reclock it, or completely disregard incoming clock signal and just use own to both decode and reclock? Because in latter case logic tells the result should depend not just on jitter but as well on realistic frequency (tolerance) difference between converter clock and DAC clock. In which case you might achieve a different audio quality not just between converter to converter but also between actual box and actual box. In other word, it might be how your Naim DAC gets along with the actual converter. Anyway this is pure speculation from my side so take it just as a guessing or thinking out loud  

 

[zalive]

On 25. 01. 2018. at 3:34 PM, nbpf said:

Thanks! https://www.naimaudio.com/sites/default/files/products/downloads/files/naim_dac_august_2009.pdf suggests that the DAC's internal clock controls both the decoding and the conversion. But my understanding is very limited and I might have misinterpreted the documentation. 

 

Thanks for this, Naim's link is very interesting read indeed...I've read half of it so far. I like when manufacturer gives insight related to their device design and specific implementation. One can learn many just by reading content like this.

 

Anyway I think this is where Naim describes reclocking approach with most detail:

Quote

RAM buffer jitter removal

Naim’s buffer or memory method of jitter removal relies

on a simple concept: the audio data is clocked into the

memory at the incoming, inconsistently timed rate and is

then clocked out of the memory and into the DAC chips

using a precise clock. The rate at which the memory fills

and empties is controlled by selecting the master clock

that best matches the average incoming clock frequency.

In this way the data entering the DAC chips is completely

isolated from the incoming jitter. Only in rare cases will

none of the Naim DAC’s selectable master clocks be

closely enough matched to the incoming data rate. To

cope with this eventuality we have also implemented, as a

backup, an asynchronous sample rate converter (ASRC).

 

Anyway I think it reveals it a bit how it't not simple to do reclocking when incoming data is synchronous (but jittery)...

[zalive]

On 19. 02. 2018. at 9:49 PM, Charente said:

@Lebouwsky ... great result Robert ! Your DAC must have a reasonable USB input ... Whilst my Gungnir MultiBit is still on Gen2 USB I'll be keeping the EITR a bit longer. I haven't bought any further tweaks for some time, other than move the EITR's PSU off the audio power strip but still on the Balanced Power Supply. Sounds impressively good to my ears. 

 

The difference between Eitr as a separate device and Gen5 upgrade is that first should offer a better galvanic isolation, while the second will avoid any S/PDIF induced jitter or noise (which depends a lot on a coax cable). Impossible to tell which is better without direct comparison test.

 

On 08. 03. 2018. at 5:49 PM, mazuly said:

It is my understanding that any 75 ohm coax cable should work such as the ones here: https://www.bluejeanscable.com/store/digital-audio/index.htm.

 

This is interesting since mine works with any cable I have connected to it including RCA audio cables.  

 

Any cable will work, but sonic results will be different, depending on length, shielding, design, materials, even connectors.

[zalive]

I'm currently using Daphile installed on Atom based small Asus laptop. Music comes from external USB HDD.

Within next few months or sooner I will probably be getting RPi + Allo DigiOne. Will be using Volumio for convenience.
This will be an interesting comparison to make. 

I've got rise time spec for DigiOne from Allo guys, and it shows that a 30-40 cm long coax should be perfect for it, which is great.