Schiit EITR

[Charente]

@nbpf ... even after installing my BPS, it still 'pops' but the occurrence is much reduced. I can't relate it to any local environment issues either ... seems random to me. Not as frequent as you are reporting tho'....perhaps once or twice a day.

 

Yes, the EITR (and DAC) are on 24/7 ... I recall an improvement during the 1st week or so, but can't say that I've noticed any further improvement since. 

[nbpf]

22 minutes ago, Charente said:

@nbpf ... even after installing my BPS, it still 'pops' but the occurrence is much reduced. I can't relate it to any local environment issues either ... seems random to me. Not as frequent as you are reporting tho'....perhaps once or twice a day.

 

Yes, the EITR (and DAC) are on 24/7 ... I recall an improvement during the 1st week or so, but can't say that I've noticed any further improvement since. 

I see, thanks for the clarifications. I will further compare M2Tech and Eitr and try to figure out what is going on!

[Charente]

@nbpf ... I am almost certain it may be power related ... you will recall our earlier conversations about this, particularly the effect of SMPS's or similar power supplies.

[nbpf]

38 minutes ago, Charente said:

@nbpf ... I am almost certain it may be power related ... you will recall our earlier conversations about this, particularly the effect of SMPS's or similar power supplies.

Right, that's what I thought in the first place. But I have done rather careful experiments. 

 

I have no SMPS attached to the power strip that powers the Eitr, the M2Tech, the nDAC, the server and the SN2. I have compared M2Tech and Eitr in situations in which I had switched off all lights and most electronic appliances in the whole flat. I have compared them in the morning and in the afternoon and I have tried moving the power supply of the Eitr and that of the server out of the power strip. I have swapped the BNC cables, the USB cables and the nDAC inputs. I have replaced the fitPC3 server with a Raspberry Pi: all with no or negligible impacts: the Eitr sounds fine but by no means better (or worse) than the M2Tech.

 

This is not a problem by itself. The M2Tech is finally powered by a fine LPSU and sounds great.  It is just that two weeks ago the Eitr and the M2Tech were easily distinguishable and now they are not anymore!

 

I think that the most likely explanation is that I misjudged the sound quality  of the Eitr when it first arrived. Afterwards I focused on comparing the Eitr and the Mutec and kept the M2Tech out of the game until I decided to return the Mutec one week later.

 

Another possibility is that during that week the Eitr has run in and its sound has in fact  shifted towards that of the M2Tech.

 

A more bolder conjecture would be that the presence of the Mutec in the power strip was actually improving the sound quality of the Eitr!

[Charente]

@nbpf ... Interesting ... I'm not at all familiar with the M2Tech but given what you say, with a decent LPSU, maybe it actually is a match for the EITR in terms of performance !!

[nbpf]

8 hours ago, Charente said:

@nbpf ... Interesting ... I'm not at all familiar with the M2Tech but given what you say, with a decent LPSU, maybe it actually is a match for the EITR in terms of performance !!

That's of course possible. The funny thing is that the M2Tech, even with external Masterclock and LPSU, is considered to be comparable to Audiophileo 2 but definitely not as good as Hydra Z, Singxer F1 and SU1, Mutec MC-3 USB, etc., see rankings in

https://www.head-fi.org/threads/xmos-xu208-usb-bridges-the-latest-gen-has-arrived.803111/page-212. The other strange thing is that I was not very much impressed by the Mutec which is generally considered to be a very fine interface. The sound was fine but somehow hard and as if the mid range was slightly recessed in comparison with bass and heights. I'll keep on experimenting and see if I can come up with some more consistent conclusions.  

[Abtr]

On ‎4‎-‎1‎-‎2018 at 11:20 PM, One and a half said:

Unless wholesale mods are performed on the Mac mini and other high leakage impedance noise sources, it is an optimum solution to leave them alone and isolate their effects somehow. 

Agreed.

 

Quote

Adding a second BPS was thought to be a bad idea since the 2nd BPS due to inherent differences in output voltages would cause more problems with the signals downstream.

Possibly.. Did you somehow experience this yourself?

 

Quote

One way around the problem of two BPS is to connect the centre points of each transformer to earth/ground. The point here is that it keeps the reference at the same potential between the two systems and any assymetric voltages are dealt with by the respective transformer noise cancellation.

A GFCI is still required for the 2nd BPS and the connections that run with that. 

How to join the two earth grounds is to open the connection covers and find a secured exit for a 4 or 6mm single green yellow wire and connect the two transformer centre points. This is simple inside a panel but using cables and connectors is doable but needs some DIY skills.

Actually the Airlink BPS units already have the (secondary) center tap connected to mains ground/Earth as standard. No need to DIY. And no need  for a GFCI *after* a BPS as long as the center tap to mains ground connection isn't lifted..

[RussL]

On 9/16/2017 at 6:10 PM, Lebouwsky said:

 

A coax cable uses two conductors using the same axis. The optimal coax cable for audio and video is exactly 75ohm, which is a measurement for resistance. The more this spec isn't met, the less signal integrity and the more signal loss. This recistance is formed by 3 variables: distance between conductors, cable length and connector geomotry. It's this last thing, connector geomotry that's got me thinking.

 

It does make me think why Schiit doesn't offer the Eitr with BNC. It also makes me think how much of the signal is getting lost. What I do know is that I want to try a shorter cable with these special Canare connectors. 

 

75 ohms as it applies to a coax cable is NOT a measure of resistance.  It is the CHARACTERISTIC impedance of the cable; two totally different things. The resistance of the cable is zero ohms.

 

It would be nice if the Eitr had a BNC connecter but how many DACs have a BNC connector?  Very few. 

 

Russ

[rayl1234]

9 hours ago, RussL said:

75 ohms as it applies to a coax cable is NOT a measure of resistance.  It is the CHARACTERISTIC impedance of the cable; two totally different things. The resistance of the cable is zero ohms.

 

It would be nice if the Eitr had a BNC connecter but how many DACs have a BNC connector?  Very few. 

 

Russ

What the DAC has doesn’t matter. You can use a bnc/rca terminated cable if needed. Advantage of bnc would be a shielded connector on at least one end. 

[RussL]

If you’re going to go BNC then go BNC all the way. 

 

Russ

[Superdad]

2 hours ago, RussL said:

If you’re going to go BNC then go BNC all the way. 

 

So that's hiphop to your DAC right? : Run BNC 

[nbpf]

On 1/20/2018 at 4:46 AM, RussL said:

75 ohms as it applies to a coax cable is NOT a measure of resistance.  It is the CHARACTERISTIC impedance of the cable; two totally different things. The resistance of the cable is zero ohms.

 

It would be nice if the Eitr had a BNC connecter but how many DACs have a BNC connector?  Very few. 

 

Russ

My DAC has two BNC and two RCA S/PDIF inputs. I have tried the Schiit Eitr with a 75cm Supra RCA-RCA cable and with a 120cm Naim DC-1 BNC-BNC cable (using a Canare RCA to BNC adapter on the Eitr side) and I cannot hear any difference between the two connections.

[Lebouwsky]

1 hour ago, nbpf said:

My DAC has two BNC and two RCA S/PDIF inputs. I have tried the Schiit Eitr with a 75cm Supra RCA-RCA cable and with a 120cm Naim DC-1 BNC-BNC cable (using a Canare RCA to BNC adapter on the Eitr side) and I cannot hear any difference between the two connections.

Strictly speaking the adapter doesn’t solve the problem of the rca’s geometry which isn’t 75ohm. If it makes a difference anyway, I don’t know. I own a Supra RCA RCA digital interlink too, it does the job well. Rumours say Schiit wil come with a more advanced Eitr somewhere in Q1 or Q2 this year, maybe with BNC connector.

 

canare sells rca plugs that come very close to the 75 ohm spec:

http://www.canare.com/ProductItemDisplay.aspx?productItemID=40

[nbpf]

7 hours ago, Lebouwsky said:

Strictly speaking the adapter doesn’t solve the problem of the rca’s geometry which isn’t 75ohm. If it makes a difference anyway, I don’t know. I own a Supra RCA RCA digital interlink too, it does the job well. Rumours say Schiit wil come with a more advanced Eitr somewhere in Q1 or Q2 this year, maybe with BNC connector.

 

canare sells rca plugs that come very close to the 75 ohm spec:

http://www.canare.com/ProductItemDisplay.aspx?productItemID=40

I am using a similar adapter:

 

https://www.audiophonics.fr/en/adapters-rca/canare-bcj-rcap-high-performance-75-ohm-rca-bnc-adapter-p-10465.html

 

I would be very interested in a more advanced Eitr with BNC connector although, to tell you the truth, I am not sure that a better USB to S/PDIF interface would improve the sound quality of my system. I have tried the Mutec MC-3+ USB. I found it different than the Eitr but not necessarily better. At the same time, I cannot distinguish the Eitr from my M2Tech hiFace Evo. I understand that the old Naim DAC overrides the clocking of USB to S/PDIF interfaces using an internal master clock. Thus, for the good or for the worse, the role of USB to S/PDIF interfaces in my system is merely that of isolating the DAC from the server+renderer. It is of course possible that new interfaces will also bring better isolation, I do not know. I understand very little about isolation.

[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. 

[nbpf]

2 hours ago, zalive said:

 

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. 

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. 

[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  

 

[nbpf]

47 minutes ago, zalive said:

 

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  

 

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. 

[FIndingit]

It seems to be part of the Schiit brand image to ignore or ridicule the details audiophiles might be interested in. They even claim that a proper 75 ohm digital cable is unnecessary to get a perfect sound from Eitr. 

[rayl1234]

58 minutes ago, FIndingit said:

It seems to be part of the Schiit brand image to ignore or ridicule the details audiophiles might be interested in. They even claim that a proper 75 ohm digital cable is unnecessary to get a perfect sound from Eitr. 

 

Though for a really short cable, that's probably true.... matching characteristic impedance reduces reflections but I suspect if you do a calculation with the approximate frequency of the digital signal and short lengths of cables, you will find no reflections in that frequency range.

 

But, as it's easy enough to get 75 ohm cable, why risk it...

[Lebouwsky]

1 minute ago, rayl1234 said:

 

Though for a really short cable, that's probably true.... matching characteristic impedance reduces reflections but I suspect if you do a calculation with the approximate frequency of the digital signal and short lengths of cables, you will find no reflections in that frequency range.

 

But, as it's easy enough to get 75 ohm cable, why risk it...

It is not easy because the Eitr doesn’t accept 75ohm connectors.

[rayl1234]

Just now, Lebouwsky said:

It is not easy because the Eitr doesn’t accept 75ohm connectors.

 

It is true that you cannot get a truly 75 ohm RCA connector... though there are some (like Canare's) that come close...

 

 

[FIndingit]

Nobody has any trouble using ISO Regen with Eitr? My Aries doesn’t see Eitr through it. Either unit could be somehow picky. 

[jcn3]

1 hour ago, FIndingit said:

Nobody has any trouble using ISO Regen with Eitr? My Aries doesn’t see Eitr through it. Either unit could be somehow picky. 

 

Alex suggested in another post that you hook everything up, but power up the ISO Regen last after everything else is on.  I'd give it a shot.