[sajunky]

USB errors are more common than you think, because there is no error correction in isochronous transfer. So the quality matters and so is the distance.

You can try running on 3m USB cable, and a 1m cable, with the same contruction, the difference will be obvious. Then if you add a reclocker you won't be able to hear the difference between a 3m or 1m one.

Not true. The only reason you hear a difference is that with the increased lenght of cable the area of a loop is increasing, collecting more EMI from arounds. And then it comes to the wrong conclusion. A truth is that reclocking devices work only because there is redirection of ground loops to the reclocking device. A proof is there: DI-20 do not do reclocking of USB source, but works better than competetive reclocking DDC's.

I truly support my statement. USB errors only happen when cable lenght increase above 5 meters. Such distance can be extended by regenerating USB frames, every hub does. You can daisy chain maximum 5 hubs. It means that your total cable lenght can be extended to the 25 meters and there is still no USB errors! Engineers who designed such system made it part of a standard. USB transfer is still bit-perfect, but ground loop surface area is increasing dramatically.

I had a power surge recently (blowing up USB hard drive and a hub) and my laptop USB ports are not well, leaking a noise from the power supply, so I suspected USB errors and made number of test monitoring USB traffic. One thing I discovered that current Amanero drivers do not use audio type asynchronous transfers, but a bulk mode like when working with hard drives. This is reported in the other thread (don't worry, transfers are still synchronised with a DAC clock, Musiland dongles use this mode). The other observation is that on the 2m ordinary quality cable USB powered hard drive still do not report errors, so no retransmission takes place. Over a dozen hours, not a single error!

 

[FredA]

Not true. The only reason you hear a difference is that with the increased lenght of cable the area of a loop is increasing, collecting more EMI from arounds. And then it comes to the wrong conclusion. A truth is that reclocking devices work only because there is redirection of ground loops to the reclocking device. A proof is there: DI-20 do not do reclocking of USB source, but works better than competetive reclocking DDC's.

I truly support my statement. USB errors only happen when cable lenght increase above 5 meters. Such distance can be extended by regenerating USB frames, every hub does. You can daisy chain maximum 5 hubs. It means that your total cable lenght can be extended to the 25 meters and there is still no USB errors! Engineers who designed such system made it part of a standard. USB transfer is still bit-perfect, but ground loop surface area is increasing dramatically.

I had a power surge recently (blowing up USB hard drive and a hub) and my laptop USB ports are not well, leaking a noise from the power supply, so I suspected USB errors and made number of test monitoring USB traffic. One thing I discovered that current Amanero drivers do not use audio type asynchronous transfers, but a bulk mode like when working with hard drives. This is reported in the other thread (don't worry, transfers are still synchronised with a DAC clock, Musiland dongles use this mode). The other observation is that on the 2m ordinary quality cable USB powered hard drive still do not report errors, so no retransmission takes place. Over a dozen hours, not a single error!

It is mostly about noise and jitter. And as far as the digital board goes, only the noise level at the exact point in time when the sampled is to be played back counts.

I am thinking that having all devices synched with the same clock helps with this target. It's like drummer in a march.

Also it is very likely that a well clocked usb source will make the task of the receiver easier, and as a consequence, the receiver will produce less noise.

I am sure Kingwa does lots of experiments including measurements to get a better understanding on these matters.

 

[sajunky]

Also it is very likely that a well clocked usb source will make the task of the receiver easier, and as a consequence, the receiver will produce less noise.

Of course, and every hub have a crystal oscilator. An accuracy of a standard crystal is sufficient for a receiver to synchronise to a bit clock. As long there are no reading errors, it is sufficient. One thing is frequently misunderstood. Bit clock is not the same as a frame clock, as frames arrive irregular. In older implementations there was some relationship, as USB host was generating frames at regular intervals, dictating sample rate. It was bad, as it carried a lot of jitter. With an adaptive mode or (currently) an asynchronous mode with an explicit end point everything is changing. There is no really a frame clock, as USB host sends frames only on the explicit request from the target. Therefore an USB bit clock (within frames) is completely separated from the sample rate.

 

[XavierP56]

@sajunky: Many thanks for such detailed explanation. Not often I read such good content on the Internet. Thanks for sharing your knowledge !

 

[Jackula]

Not true. The only reason you hear a difference is that with the increased lenght of cable the area of a loop is increasing, collecting more EMI from arounds. And then it comes to the wrong conclusion. A truth is that reclocking devices work only because there is redirection of ground loops to the reclocking device. A proof is there: DI-20 do not do reclocking of USB source, but works better than competetive reclocking DDC's.

I truly support my statement. USB errors only happen when cable lenght increase above 5 meters. Such distance can be extended by regenerating USB frames, every hub does. You can daisy chain maximum 5 hubs. It means that your total cable lenght can be extended to the 25 meters and there is still no USB errors! Engineers who designed such system made it part of a standard. USB transfer is still bit-perfect, but ground loop surface area is increasing dramatically.

I had a power surge recently (blowing up USB hard drive and a hub) and my laptop USB ports are not well, leaking a noise from the power supply, so I suspected USB errors and made number of test monitoring USB traffic. One thing I discovered that current Amanero drivers do not use audio type asynchronous transfers, but a bulk mode like when working with hard drives. This is reported in the other thread (don't worry, transfers are still synchronised with a DAC clock, Musiland dongles use this mode). The other observation is that on the 2m ordinary quality cable USB powered hard drive still do not report errors, so no retransmission takes place. Over a dozen hours, not a single error!

I never said EMI wasn't a factor, but errors are also an issue. You do know how isochronous transfer works? At one of my previous work we had the equipment to detect transfer errors as we were using it to test white box encryption using quantum noise as encryption key, for this to work transfers need to be accurate. However when using generic USB cables there are a lot of errors during transfer, you don't see this because it's all auto corrected. We ended up using optical fibres but that also had other issues like chromatic dispersion.

Try my suggestion with and without isolation and with and without reclocking and see that both make a difference.

BTW I highly appreciate your posts on science, but have to jump in where I have difference of experience to back up.

 

[FredA]

I never said EMI wasn't a factor, but errors are also an issue. You do know how isochronous transfer works? At one of my previous work we had the equipment to detect transfer errors as we were using it to test white box encryption using quantum noise as encryption key, for this to work transfers need to be accurate. However when using generic USB cables there are a lot of errors during transfer, you don't see this because it's all auto corrected. We ended up using optical fibres but that also had other issues like chromatic dispersion.

Try my suggestion with and without isolation and with and without reclocking and see that both make a difference.

BTW I highly appreciate your posts on science, but have to jump in where I have difference of experience to back up.

Is there actual error correction on the usb audio data? I am surprised.

My own experience with usb cable is since i got a really good one, my usb transport rarely needs a reboot. Sound qualiity made quite a jump too. The good news is i won't be looking for a usb cable anytime soon.

 

[DACLadder]

The isochronous layer has no error correction but these ‘layers’ or collections of audio samples are packetized in the USB physical data frame which also has its own headers/ timestamps/CRC checksums, etc. If the USB receiver detects an uncorrectable error the USB frame is dropped or repeated. The big take away is these isochronous layers are transmitted at 125us rates. The faster the sampling rate the more samples are pack into the isochronous layers.

Yea, USB errors are bad. Built in error testing would be great for cable selection!

This is a fairly good easy read on basics of USB audio. https://www.edn.com/fundamentals-of-usb-audio/

 

[FredA]

Thanks, Scott.

 

[borrego]

The isochronous layer has no error correction but these ‘layers’ or collections of audio samples, are packetized in the USB physical data frame which also has its own headers/ timestamps/CRC checksums, etc. If the USB receiver detects an uncorrectable error the USB frame is dropped or repeated. The big take away is these isochronous layers are transmitter at 125us rates. The faster the sampling rate the more samples are pack into the isochronous layers.

Yea, USB errors are bad. Built in error testing would be great for cable selection!

This is a fairly good easy read on basics of USB audio. https://www.edn.com/fundamentals-of-usb-audio/

In the past 4 years I have been using the Icron Ranger 2304GE USB extender to overcome the lack of error correction in USB isochronous transmission. The Icron USB extender adds handshaking, transmission retries, and caching to USB isochronous data transfer: https://patents.justia.com/patent/7149833

The result is so satisfying to the point that I am not tempted adding any DDC like the DI-20 and external clock to my M7S, but relying on the internal Amanero interface.

Icron now provides similar function to USB 3.0 superspeed transmission: https://patents.justia.com/patent/20200167304

 

[Crow123]

In the past 4 years I have been using the Icron Ranger 2304GE USB extender to overcome the lack of error correction in USB isochronous transmission. The Icron USB extender adds handshaking, transmission retries, and caching to USB isochronous data transfer: https://patents.justia.com/patent/7149833



The result is so satisfying to the point that I am not tempted adding any DDC like the DI-20 and external clock to my M7S, but relying on the internal Amanero interface.

Icron now provides similar function to USB 3.0 superspeed transmission: https://patents.justia.com/patent/20200167304

This costs more than a di20 though ?

 

[borrego]

This costs more than a di20 though ?

I recalled it costed below USD400 including shipping from Canada to Hong Kong 4 years ago. The REX unit has 4 USB ports so one can connect up to 4 DACs.

 

[sajunky]

This costs more than a di20 though ?

I wouldn't even bother, even it is cheaper. Many patents these days are not working. There is no a requirement to prove in a real environment that a proposed application is effective. I am not saying that this particular device is not working well. There are typically other things which are working, but for marketing purpose a working part is hidden behind a nonsense patents.

There is no provision in USB isochronous transfers for a packet retransmition. Just CRC check and an action is to drop a frame. Ranger xxx is not able to change it. A reason is that timeslots for the transmission are reserved in advance (when opening a device for a transfer), there is no mechanism to increase a pipe diameter dynamically. Secondly, isochronous packets arrive in order. And finally, timing is a critical factor. It is mentioned 125us for a timeslot. It is actually a microframe. Eight consecutive microframes constitute one high-speed frame (around 1ms). This is on the hardware PHY level. On the low system level there is a queuing system, hardware interrupts are programmed in advance to wake up a relevant portion of a software for transmitting individual frames. Bypassing a queue could result in insufficient service level for other devices (even a timeout errors).

The above is about asynchronous transfers. Amanero Windows drivers actually use a different transfer mode, bulk transfers. In a bulk mode there is a provision for retransmission of packets. Do Amanero make such requests? Honestly, I don't know, I didn't see any. It is why I started to test a hard drive, as I know for sure it would be retransmission requests, but again, I didn't see any. Errors appeared only when I switched to a 3m cable, and it was not a few, but plenty. Hard drive draws a lot of current, it is why errors came up on a relatively short cable. A DAC should work reliably on a longer cable without errors. My conclusion is that in a normal situation (when cable lenght is kept according to the recommendations) there is no errors on the USB transfers. When errors come, it will likely cause protocol errors and timeouts stopping the transfer.

You did mention planning to use iFi Defender, no reclockers, this device makes sense. It is a sign that you are resisting marketing rubble unlike many others. Maybe I should order one.

 

[XavierP56]

Would ifi Purifier 3 Type B make sense with R7-HE21 or is it just bull ?
(ifiDefender /ifiSilencer has no Type B port)

 

[Crow123]

Would ifi Purifier 3 Type B make sense with R7-HE21 or is it just bull ?
(ifiDefender /ifiSilencer has no Type B port)

I have the ifi purifier USB that I use with my SMSL M500 it was an impulse purchase. With the SMSL M500 it did make a diffence to quieter background this was a noticeable change (as opposed to a critical listening based observation) now given price point I assume USB implementation is no where near as good as R8.

I do think the noise rejection makes sense just not sure if it will make a difference in R8 or actually be worse and therefore make signal chain worse than just pure from pi4?

 

[sajunky]

The only things that works in such devices is this:

Just don't buy a claim about 'intelligently' disconnecting from ground loops. It is a common knowledge that current flows the easiest way.