New Audio-gd R-7, R-7HE R-8, R-27, R-27HE, R-28 Flagship Resistor Ladder DACs and DAC/amps
Jun 19, 2021 at 12:10 AM Post #7,261 of 8,794

Jackula

100+ Head-Fier
Joined
Dec 5, 2012
Posts
276
Likes
309
USB signal is passing without errors, as errors on the USB connection are very rare. With asynchronous transfers a source frequency and timing is no problem as USB clock is slaved to the internal clock - as long as there are no receiving errors, but again errors are very rare. 5V is not used, no problem. Problem is with a noise on the ground wire. It creates a current flow inside a DAC through the internal power supply for the Amanero module. It creates EMI spreading inside a DAC. There is also interference between other sections of a power supply, and finally a galvanic isolation which is placed between Amanero and FPGA core logic is not perfect. Any capacitance (even very small) between components of a dirty side and a core logic create leak.

In other words, USB give perfect bit transfers, therefore any USB reclockers do not make any sense, the only concern is a noise entering inside a DAC.
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.
 
Jun 19, 2021 at 10:13 AM Post #7,262 of 8,794

sajunky

Headphoneus Supremus
Joined
Mar 19, 2020
Posts
1,874
Likes
1,148
Location
South Africa
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!
 
Jun 19, 2021 at 11:03 AM Post #7,263 of 8,794

FredA

Headphoneus Supremus
Joined
Dec 15, 2013
Posts
4,330
Likes
2,246
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.
 
Jun 19, 2021 at 11:43 AM Post #7,264 of 8,794

sajunky

Headphoneus Supremus
Joined
Mar 19, 2020
Posts
1,874
Likes
1,148
Location
South Africa
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.
 
Jun 19, 2021 at 8:17 PM Post #7,266 of 8,794

Jackula

100+ Head-Fier
Joined
Dec 5, 2012
Posts
276
Likes
309
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.
 
Last edited:
Jun 19, 2021 at 8:54 PM Post #7,267 of 8,794

FredA

Headphoneus Supremus
Joined
Dec 15, 2013
Posts
4,330
Likes
2,246
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.
 
Jun 19, 2021 at 9:38 PM Post #7,268 of 8,794

DACLadder

Headphoneus Supremus
Joined
Feb 16, 2013
Posts
2,158
Likes
1,575
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/
 
Last edited:
Jun 20, 2021 at 3:02 AM Post #7,270 of 8,794

borrego

1000+ Head-Fier
Joined
Jun 19, 2008
Posts
1,236
Likes
323
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

Icron.JPG


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
 
Jun 20, 2021 at 3:45 AM Post #7,271 of 8,794

Crow123

New Head-Fier
Joined
Jun 17, 2021
Posts
45
Likes
54
Location
South Africa
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

Icron.JPG

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 ?
 
Jun 20, 2021 at 7:07 AM Post #7,272 of 8,794

borrego

1000+ Head-Fier
Joined
Jun 19, 2008
Posts
1,236
Likes
323
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.
 
Last edited:
Jun 20, 2021 at 7:57 AM Post #7,273 of 8,794

sajunky

Headphoneus Supremus
Joined
Mar 19, 2020
Posts
1,874
Likes
1,148
Location
South Africa
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.
 
Last edited:
Jun 20, 2021 at 1:30 PM Post #7,275 of 8,794

Crow123

New Head-Fier
Joined
Jun 17, 2021
Posts
45
Likes
54
Location
South Africa
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?
 

Users who are viewing this thread

Top