[LarryMagoo]

it's right here...easy peasy
 
http://www.ebay.com/itm/FUN01-XU208-XMOS-USB-Audio-Digital-Interface-XLR-AES-fiber-coaxial-LPS-/322214870575?hash=item4b0580be2f:g:x4cAAOSwqfNXoX0W
 
Just find it hard to believe that $210 box could improve my Yggy

 

[Tboooe]

  Here are 2x HDMI cables that I will soon be comparing - the 0.3M WireWorld and the 0.5M Supra

 
The Supra is considerably longer - which is what I need based on my current configuration.

 
With everything stacked, I need a little more length than I can get with the WireWorld.

 
If it turns out to be audibly better, I will try rearranging my stack to use the shorter cable.

Is that the Wireworld Ultraviolet?  Based on the recommendation by @Energy I picked up the 0.5m Apollo.  It looks like a very well built cable.  I am going to compare the Apollo to my el cheapo $8 HDMI cable.  Based on your findings I may try the Ultraviolet too. 

 

[Superdad]

So you recommend attaching the ISO Regen to the Singxer SU-1 through a Male to Male adapter so that the characteristic impedance doesn't affect signal integrity that much as it's short?

Also, what is your perspective on the partial galvanic isolation within the Singxer SU-1?

Since your ISO Regen already offers full galvanic isolation through the use of Silanna ICE08USB chip, wouldn't going through the extra isolation within the Singxer SU-1 add latency among other things such as impedance mis-match, packet noise modulation, frame noise, ground noise, and degrade signal integrity? Wouldn't it be better to bypass this entire area and send the data directly to the clock side of the board?

My theory is that if true galvanic isolation is present, anything extra will degrade the regenerated signal. Like with the isolation inside the Singxer SU-1 prior to the reclocking phase. Since it uses asynchronous XMOS and vbus power for it's duties, I suspect it's not transparent.

Because of this sole reason, I figure it would be best to have an ISO Regen (or iGalvanic 3.0) and pair it with a DDC that doesn't offer extra isolation. The problem with this however is that it's hard to find a standalone DDC that offers a good clock like the Crystek CCHD-575.. Correct me if I'm wrong.

A lot to unpack there--wish I knew the easy way to multi-quote a single post so I could type in between your questions.
 
Starting form the top:  
Yes, any USB device (management frowns on my referring to our own) that improves SI and impedance deserves to be mounted right at the input of the DAC or converter to preserve those qualities. Running another cable just modifies that SI/impedance.
 
The digital isolators in the SU-1, just like the digital isolators in all DACs that use such, are placed AFTER the USB input PHY and USB processor.  And while they are good at blocking some things, anything that happens to the signal before them gets "baked in." The proof is that you hear differences with upstream stuff--USB cables, computer stuff, power supplies, USB "regenerators", etc.  And the reason you do hear it is not because the data from the computer is "dirty"--it's not.  It is because the DAC/DDC's input PHY is a nasty, complex little beast with the tough job of decoding data bits from the analog voltage coming in.  And the harder it has to work, the more it generates ground-plane and packet-data noise voltage of its own.  Pernicious stuff, and the digital isolators afterwards can not block it all: remember, they have to pass the data.
 
My partner John Swenson explains this stuff much better so:
"Even using isolators does not completely block jitter. I'll try and get this across without pictures. A signal goes into the USB side of the isolator, current flows from the driver, through the input side of the isolator (whatever it is) and back through the plane to the driver chip. That signal passes through the isolator some how (light, magnetic field, radio waves, whatever) (yep one of the isolator technologies actually sends radio waves between the sides) and causes the receiver side to do something, which changes the signal on it's output. That output then drives the DAC chip or reclocking flop, which then sends the current back to the isolator output on the ground-plane. The current ALWAYS goes in loops, thus the signal going to the DAC chip creates noise on the DAC side ground-plane. 
 
Thus any jitter on the signal crossing the isolation barrier is added to the inherent jitter of the isolator and that shows up as noise on the DAC side ground plane, even with the isolator! What the isolator does is prevent OTHER GPN such as being produced by the USB receiver itself from getting into the DAC groundplane. It's definitely worth it, but you still have to deal with the jitter on the I2S signals themselves which cross the barrier.
 
Because the I2S signals are fairly jittery after the isolators, you usually should reclock them before sending them to the DAC chip. Why do you need to do this? Isn't the jitter on the clock the only signal that matters? Because GPN also happens INSIDE the DAC chip. Jittery input signals generate noise on the ground traces in the DAC chip, which change how the clock signal is received. You can have an extremely low jitter clock going into the DAC chip, but if the I2S signals are very jittery, the GPN inside the chip will cause that ultra low jitter clock to look MUCH worse. 
 
So you still have to look at the jitter on the I2S signals, even with a perfect clock. 
 
There are ways to cut down on these issues by careful board layout, but you have to include these as part of the overall design from day 1 to make sure they will be effective. But even with this, some influence still gets through."
--John Swenson, November 2014
 
By the way, as an example, the TI ISO7461 isolators as used in the SU-1 themselves add about 600 picoseconds of jitter--so at least a flip-flop for reclocking should be on the other side.  I am sure the SU-1 takes care of that in the Xilinx FPGA the isolators feed right into.
 
Back to you questions:
Sorry, but your 3rd paragraph ("extra isolation within the Singxer SU-1 add latency among other things such as impedance mis-match, packet noise modulation, frame noise, ground noise, and degrade signal integrity? Wouldn't it be better to bypass this entire area and send the data directly to the clock side of the board?") does not make sense in the context of what goes on after the XMOS processor and into the TI isolators, nor would it be a better thing to bypass the isolators.
From what I can see in the SU-1 on my desk, it looks like they bus power the entire USB input side (which is not much more than the XMOS and voltage regulators for it), so they can have just one power supply (with separate ground plane) for all the stuff on the other side of the 'moat'.  This is quite common (even the Berkeley Alpha USB does it).  So that's where the isolators on the I2S lines (between the XMOS and the FPGA) come into play.
 
You then say: "My theory is that if true galvanic isolation is present, anything extra will degrade the regenerated signal. Like with the isolation inside the Singxer SU-1 prior to the reclocking phase. Since it uses asynchronous XMOS and vbus power for it's duties, I suspect it's not transparent."
 
No offense, and maybe it is me, but that seems a bit of a word salad.  Improved SI (the "regenerated signal" as you refer to it) helps the DAC/DDC's input PHY--that's all.  There is no cutting out a USB MAC processor (be it XMOS, Cmedia, or one that a DAC maker goes to the trouble of doing in an FPGA, such as Amenero or exaSound) from the path, and whatever noise they generate (on the ground plane or elsewhere) is not improved by what comes before--so the isolators afterwards have their place.  (There are however, much better isolators than those ubiquitous TIs; the NVE GMR type are a lot better.)
 
As for galvanic isolation before the DAC/DDC, done right it is effective blocking leakage currents and other crap coming from the computer, so that is quite worthwhile.  But without really great signal integrity, low noise regs, and a great clock, the results are not great.  For example, there have been other high speed USB galvanic isolators out there using just the Silanna chip--without a hub chip (not referring to any hi-fi market competitors here, nor to the FPGA-based Intona, just the few industrial units).  But the Silanna chip by itself adds lots of jitter--about the same 600ps at high speed that one gets from the TI ISO7461 in the SU-1.  (I have a couple of those units, and boy are they a lesson in what added jitter sounds like!)
 
​So I guess I am about done.  I hope the above begins to make things a little clearer.  There are no short-cuts.  And the funny thing is, when you start to do true galvanic isolation between components (which just means creating high DC resistance along all pathways), other things can happen.  EMI and static charge build-up may no longer have easy paths to "drain"/discharge to.  With one version of the ISO REGEN I had weird ticks start after 3-5 minutes of playing.  We chased that for weeks until I realized that EVERY piece of equipment in my main system is "floating"--with power cords that have their ground wire lifted.  When I gave just one component (preamp, amp, whatever) a real ground, the problem went away (but the galvanic isolation is still perfectly intact).  There are still aspects of that which keep me scratching my head.
 
One thing I will say (will this get me banned or will the mods finally return my messages about sponsorship here?), is that the biggest sonic leap with the forthcoming ISO REGEN is not the galvanic isolation.  It is all the other major enhancements we have made.  Those expensive enhancements have been on our prototype boards for over a year while we fussed with getting the Silanna isolator to play nice.  I'm kicking myself that we did not just release an uber-REGEN in April 2016.  But now the ISO REGEN boards are on order and arriving this coming month, so our ordeal is almost over and the fun will soon begin.
 
Have a great weekend everyone!
 
--Alex C. 
 
 

 

[Superdad]

SU-1 reverses channels when fed DSD!!
 
Oh no, the dreaded DSD channel reversal.  I've seen it before, but I was bummed to just discover that the SU-1, when fed DSD (via DoP in my case) and outputting over I2S to the Holo Spring reverses channels. 
 
I understand that Kitsune is presently working with Singxer on new firmware (for other enhancements), so I am going to e-mail Tim now about this.
 
Hope they can address this soon.  

 

[Tboooe]

SU-1 reverses channels when fed DSD!!

Oh no, the dreaded DSD channel reversal.  I've seen it before, but I was bummed to just discover that the SU-1, when fed DSD (via DoP in my case) and outputting over I2S to the Holo Spring reverses channels. 

I understand that Kitsune is presently working with Singxer on new firmware (for other enhancements), so I am going to e-mail Tim now about this.

Hope they can address this soon.  :eek:

Alex, I believe the current firmware listed on the Kitsune website fixes this issue.

 

[LoryWiv]

  SU-1 reverses channels when fed DSD!!
 
Oh no, the dreaded DSD channel reversal.  I've seen it before, but I was bummed to just discover that the SU-1, when fed DSD (via DoP in my case) and outputting over I2S to the Holo Spring reverses channels. 
 
I understand that Kitsune is presently working with Singxer on new firmware (for other enhancements), so I am going to e-mail Tim now about this.
 
Hope they can address this soon.  

Is there a jumper setting on the SU-1 specific for your DAC that will correct this? I may be wrong but I thought the bottom of the unit had jumpers that some DAC's required for proper DSD output.

 

[Superdad]

Alex, I believe the current firmware listed on the Kitsune website fixes this issue.

 
Oh wow, thank you Tommy!   Of course being an XMOS unit, there is only the Windows DFU firmware updater.  So tomorrow I'll drag the SU-1 over to my son's Windows machine to load the new firmware.
 
One question though:  The download contains 2 versions of the updated firmware--2-00 and 2-02, and the web site says the only difference between them is channel position for DSD--and to choose according to your DAC.  That only half makes sense as it is the SU-1 reversing channels, and the Holo Spring does not reverse channels on DSD when fed via its USB input.
So is the implication that I2S input channel assignments vary?  I'm confused, though of course I'll choose the right one.
 
By the way, I'm grooving right now to a live Harry Manx album I just got.  Sounding fiiiiine...  

 
Good night,
--Alex C.

 

[rafabro]

The latest version of drivers (available on shenzeaudio) is 3.34 and this contain firmware 2.20. So that's the latest official version.

 

[Cable Monkey]

The latest version of drivers (available on shenzeaudio) is 3.34 and this contain firmware 2.20. So that's the latest official version.

So what is the process of updating that firmware? Simply applying the drivers in Windows or is there more to it?

 

[rafabro]

That one file you can download is archive .RAR which contain drivers, manual and tool to update firmware.
After you install XMOS drivers, folder: C:\Program Files\XMOS\USBAudioStDriver_3086  will contain "xmosusbaudiost3086_dfuapp" file which is the tool to check and/or update fw.

 

[jcn3]

The latest version of drivers (available on shenzeaudio) is 3.34 and this contain firmware 2.20. So that's the latest official version.

The 3.34 version seems to have the 2.0 firmware not 2.2. Is there any place else to get the 2.2 .bin file?

I'm using an F-1 but wouldn't think that would matter as they're both using the same hardware.

 

[oneguy]

The other question is: if this is a known issue and has been for sometime now, why don't they ship from the factory with he most up-to-date firmware?

 

[Superdad]

  The latest version of drivers (available on shenzeaudio) is 3.34 and this contain firmware 2.20. So that's the latest official version.

That is incorrect.  The driver s/w (yes, 3.34) is separate from the firmware files, and the latest releases firmwares are 200 and 202.  The only difference between the to firmware files is the DSD channel assignment.  
 
It has been explained to me that with I2S different DACs assign the channels differently.  My SU-1 came loaded with firmware 202, but for the Holo Spring I will need to load 200 to get the channel assignment correct for DSD.

 

[joseph69]

I've been listened for the past 1-1/2hrs (without the mR) in my chain and have found I'm very impressed with the KTE SU-1 unlike the SU-1 which wasn't impressive to me, leaving me to actually prefer my chain without it.
 
Now, as soon as I put the mR back into my chain I immediately noticed the mR very noticeably pushed the performance of the KTE SU-1 to another level by enhancing the clarity/height/depth/separation/imaging/sound-stage and decay of the music. I would describe it as a "liveliness" being added to everything the KTE SU-1 already has to offer. So from what I'm hearing, both the mR/KTE SU-1 definitely work extremely well together in my chain.
 
I  mentioned in a prior post when I received my KTE SU-1 and already had the mR in my chain, that everything sounded as if it were on a much grander scale and didn't know which should be credited. I've come to the conclusion that it is both the mR/KTE SU-1 working side by side bringing me this musical enjoyment I've been experiencing. 
 
PS: I Also experienced another drop out which would occur once (maybe twice) each listening session while I was writing this without the mR in my chain. This only adds another reason for my preference of AoIP being I never experience any drop out issues whatsoever while using it.

 

[oneguy]

The 10 cm ribbon HDMI cable and the 10 cm traditional HDMI cable arrived. I am still waiting on the 90 deg adapter for the traditional cable so no opinions on it yet.

For the ribbon cable, the voices seem a little hazy but it's only been operating for 10 min so that could change. I'll give it 2-3 days of continuous play and see if it improves. Right now my benchmark for comparison is an Emotiva 0.5 m HDMI cable.

I am awaiting an HDMI cable from Apollo AV but they sent me wrong order so it will be another couple of weeks to get that sorted.