[FredA]

It often starts up with either issue on boot-up, so I have to troubleshoot it every boot-up by cycling between P / S modes unless I'm lucky

Skipping a song does not fix this? Or else you should be fine just rebooting the computer. I never noticed this issue. But i don't.switch often between P and S.

 

[ProLoL]

Never had a single issue via I2S, no static nor reversed channels, simply perfect. I don't see another reason using a different input, other inputs aren't asynchronous.

 

[Wynnytsky]

But at least the issue doesn't come back until touching any buttons or turning it off.

perhaps I've been spared because I don't turn the thing off or push it's buttons.

I don't see another reason using a different input, other inputs aren't asynchronous.

I didn't know that about i2s.
I recall video cards working by filling a video frame buffer async that is sampled asynch 60..240 times a second by the monitor, and freesync/g-sync + displayport is supposed to allow the monitor to grab+paint frames as fast as they are completed instead of using a fixed rate that opens you up to teared and skipped frames.

 

[ProLoL]

The spdif / optical signals are packed into code, transferred to the dac's receiver chip which unpacks the code, that packing and unpacking can cause a loss of data.
AES is the same just a balanced spdif. I2S avoids it, making two devices become one instead of one device speaking to another.

 

[Wynnytsky]

The spdif / optical signals are packed into code, transferred to the dac's receiver chip which unpacks the code, that packing and unpacking can cause a loss of data.
AES is the same just a balanced spdif. I2S avoids it, making two devices become one instead of one device speaking to another.

for spdif or i2s, are either of them slaving one device (ex: dac) to the other device's clock (ex: di20)? Or is the external clock the only way to get them dancing to the same tune?

from your above explanation, can one speculate that one of the protocols (spdif vs i2s) would benefit more from an external clock?

 

[PLGA]

Well, I don't know so much about tech aspects of it, but I've tried, between my DI-20 and R8 DAC, I2S connection with two different cables (0.5m BJ Belden and 0.6m Moishou) and I prefered AES/EBU. It sounded more rounded and natural, less harsh.

I know both HDMI cables mentioned are cheap, but recomended on this forum as good ones. Also the AES/EBU (XLR) cable I tried was a not expensive chinese one and 1m long, longer than the HDMI ones.

I don't know, I might try it again over time, but there are SO MANY possible combinations that I feel I will never stop trying and trying and that's time consuming against our time to just enjoy music. As a rule, I generally don't spend much time doing A/B comparisons. If there is a noticeable difference in sound quality between two settings, or two different equipments, I must feel it right away and with out any doubt about it. If not, it's not worthwile to spend time on it.

 

[Wynnytsky]

I prefered AES/EBU. It sounded more rounded and natural, less harsh.

can't help but wonder if i2s' tighter tolerances has a greater need for a common external clock
and perhaps the consequence of not having that is that harshness that we hope to solve with cables

 

[Articnoise]

Received my DHL notice that my DI-20HE has begun its slow journey to my listening station. I also ordered a Maze Audio Ref4 SE 10-AWG power cord (matches the 3 I have in use now for R-27 & ADAM Audio speakers) as well as a Wireworld Chroma 7 HDMI cable (read somewhere kingwa had recommended it for this use).

Any tips for a new owner? I understand it needs upwards of 500 hours of burn-in. Is there a recommended method to speed that up? I also has a PS Audio LANRover that I have between the Dell laptop and the R-27. My understanding based on reading here is that it may or may not provide any benefit going forward. Should I leave it out until burn-in is done?

5-6 days of burn in and it will sound splendid. After that just keep it on 24/7 and play music when you want to listen. Good server and cables are mandatory thou if you want to experience how good the DI-20HE really is.

 

[FredA]

for spdif or i2s, are either of them slaving one device (ex: dac) to the other device's clock (ex: di20)? Or is the external clock the only way to get them dancing to the same tune?

from your above explanation, can one speculate that one of the protocols (spdif vs i2s) would benefit more from an external clock?

Both are asynch with the r7 and m7s. And the newer audio-gd dacs.

 

[sajunky]

for spdif or i2s, are either of them slaving one device (ex: dac) to the other device's clock (ex: di20)? Or is the external clock the only way to get them dancing to the same tune?

from your above explanation, can one speculate that one of the protocols (spdif vs i2s) would benefit more from an external clock?

Iin S/PDIF clock is embedded in the data stream (needs to be recovered). Such recovery is jittered, it needs a lot of care.

With I2S there is a real hardware clock line (external clock), it must be clean. There is no synchronisation back like in USB protocol, so this clock is a master. Most of DAC's including chip DACs have native support for I2S, can be fed directly. While jitter is already low, it can be improved. How it can be improved, it is a matter for a different topic. A device may use I2S clock as a master or generate its own master clock, it is probably how it is made in DI-20.

 

[Wynnytsky]

@sajunky
So if I read the above correct, neither spdif nor i2s can share a master clock signal over the coax or hdmi alone. Both participating devices would need to be networked to an external clock via 50/75ohm BNC cabling (series or parallel).

So whether my di20he uses it's internal oxco or the external Morion doxco, even if my r2r7's oxco is identical in spec, there must be some phase shift between the two clocks. The exact shift is determined by the moment in time that I turn these devices on. Assuming 180 degrees is the worst shift, I wonder if that's enough to make it a bad listening session? And then what duration of time would need to elapse before these clocks naturally drift back into perfect phase?

And if clock phase is a real thing, are those GPS clocks accurate enough that you could operate two of them (no sharing) in perfect phase @10mhz?

 

[sajunky]

I don't know why you need to preserve phase. BTW, one of the most precise some methods of synchronisation, FIFO introduce delay in a row of number miliseconds to the input samples and you talk about 180 degree phase shift of the clock. I seem something failing to follow.

AFAIK, all inputs can be synchronised with master clock if enabled in settings. As for 'HDMI' in DI-20, it is just I2S solution utilizing HDMI connector. It has nothing to do with HDMI.

My previous post actually repeat what @ProLoL wrote before, sorry I didn't see it.

 

[FredA]

@sajunky
So if I read the above correct, neither spdif nor i2s can share a master clock signal over the coax or hdmi alone. Both participating devices would need to be networked to an external clock via 50/75ohm BNC cabling (series or parallel).

So whether my di20he uses it's internal oxco or the external Morion doxco, even if my r2r7's oxco is identical in spec, there must be some phase shift between the two clocks. The exact shift is determined by the moment in time that I turn these devices on. Assuming 180 degrees is the worst shift, I wonder if that's enough to make it a bad listening session? And then what duration of time would need to elapse before these clocks naturally drift back into perfect phase?

And if clock phase is a real thing, are those GPS clocks accurate enough that you could operate two of them (no sharing) in perfect phase @10mhz?

A phase shift has no incidence with an asynch dac.

 

[Wynnytsky]

@sajunky
If I'm synch'ing both DI20 and DAC, then I would assume one external clock is better then two external clocks, no?
If I were asked what's wrong with two external clocks I would think it's because the 10M-per-second peeks don't line up perfect (that I was calling phase shift).
Is that synchronicity also important (accuracy asside)?

 

[jase01]

I thought it was supposed to be burned in with music playing, though I may have my 'wires crossed'.

Also another issue I've been having with the 4.07 Beta firmware is reversed channels. I didn't always notice it until I starting doing either a manual sound test on the Windows playback device properties that does a 'ping' in the left channel first then the right channel, or by playing a song which has a sound on the right or left channel that you're familiar with, revealing it starts up with the channels reversed a good percentage of the time.

I mentioned the same thing in post 1907. Good to know I wasn’t hallucinating! Mine occurred on initial start up of the DI-20HE but after 24 hours it had returned to normal, without my having changed anything or power cycled. Periodic checks since (I find it easiest to use an audio test album with left and right channel identification tracks) have all revealed left and right channels to be correct.