[SwissBear]

I kind of struggled with the update process of the Amanero driver.
I wrote this (inspired from Amanero instructions) in order to help others.

How to upgrade the Amanero firmware to operate in full DSD (instead of DoP) with Linux devices (and in connexion with SOtM sMS-200 devices)

(prerequisite is a PC with MS Windows OS, or a Mac with Parallel software)

1) Unzip the update tool ( https://amanero.com/oemtool117u.zip ) downloaded from amanero.com, into a folder, for example on Desktop.

2) ERASE THE FLASH
Connect the DI20-HE to your computer using USB cable. Press the update button for 2 seconds. Then unplug the USB cable and shut the DI20-HE down.
Reconnect the USB cable and power the DI20-HE up.

3) When you replug the erased device, Windows can ask about a driver.
The needed driver info file atm6124_cdc.inf is among the unzipped files.

4) Be sure to be connected to internet.

5) Run ConfigTool.exe, select the CPLD firmware version (Use CPLD_for_1081 or CPLD_1081_SWAPPED) and press FLASH CPLD.

6) Wait 3-4 seconds then Unplug the USB cable and Replug it again

7) Select the CPU firmware version (Use firmware_2006be11). Press FLASH CPU and when done unplug the USB cable

8) Replug the USB cable and if it's all ok the audio driver needs to detect the device.

 

[myshark]

Hi everyone, any advice on this one ?

Hi, u should try all 3 and decide for yourself. Also on parallel or serial mode. Pls bear in mind di20 needs burn in time...long time.

Enjoy.

 

[SwissBear]

Hi, u should try all 3 and decide for yourself. Also on parallel or serial mode. Pls bear in mind di20 needs burn in time...long time.

Enjoy.

Thanks you. I will obviously decide for myself . I have to say that I am always a little bit puzzled when I see forks in software development. So I was kind of looking for an advice on the 3.933 in relation to Mutec Ref-10, and check whether this version was bringing serious improvements in supporting an external clock which delivers square signals and not sinusoidal ones...
Thanks for the warning on burn-in time. I was wondering whether the oscillators were the longest to burn in or if the whole machine needed such a long time. The return policy of the company which sold me the device is 15 days. So I need to make my personal idea withing this time frame, which is short in relation to the 300 hours which are advised as burn-in time.

 

[Thenewguy007]

I believe the biggest difference with the firmware is tone. With the two latest ones being more warmer sound.

I would definitely try the latest one though, to see if there was any improvements to the clocking function.

 

[jazzbug]

The latest 3 versions have received compliment by lots of ppl here, but still depends on your own system synergy, and best to try out all, such a beauty of FPGA updates from Kingwa.
For me its still 3.933

 

[SwissBear]

Thanks to the three of you for sharing your thoughts. I appreciate
I have tried the 3 versions and I better understand your recommendations.
I have to say that I personally have a preference for the tonal neutrality of 3.933.
Thanks again.

 

[cs098]

has anyone compared it to the Berkeley alpha audio usb?

 

[smodtactical]

Anyone have a problem where this monotone comes on like a higher pitched sound comes on. It won't go away until I restart the di20he, and gotta leave it off for a good few minutes, then its back to normal and works fine. Happens once in a while, maybe once a week or something. I an updated to the latest firmware. Is it overheating ?

 

[FredA]

Anyone have a problem where this monotone comes on like a higher pitched sound comes on. It won't go away until I restart the di20he, and gotta leave it off for a good few minutes, then its back to normal and works fine. Happens once in a while, maybe once a week or something. I an updated to the latest firmware. Is it overheating ?

I have had a similar problem. Skipping or restarting the song would cure it. I think it was caused by the amanero underflowing or something like this. I think it's due to latency. My streamer is the usbridge sig. Using a better usb cable made the problem almost disappear. It happens once every two weeks now or less. When using the rpi4b, i never had this issue.

 

[sajunky]

I have had a similar problem. Skipping or restarting the song would cure it. I think it was caused by the amanero underflowing or something like this. I think it's due to latency. My streamer is the usbridge sig. Using a better usb cable made the problem almost disappear. It happens once every two weeks now or less. When using the rpi4b, i never had this issue.

Good observation, it is true due to the latency on one side, but ground loop noise is a clulprit in most cases, so a different cable can reduce effect, it may even eliminate if lucky.

On my laptop as a source it happens when synchronous transfer mode is selected, the same happens on three different DACs tested. One has Amanero drivers, second one XMOS, the third use built in Windows drivers (CM108 chip). All of them lose synchnronisation at times, producing similar distortions. A time to recover vary, depends on the chip. CM108 is the worst one.

I have a bit-perfect configuration in Foobar, so load of the system is minimal and DPC latency is in control, but it still happens when using WASAPI push mode. It indicate excess of noise on my cheap cable. When switching to the WASAPI event mode effect is different. Now there are two cases, it will help you recognise a cause:

1. DPC latency problem on PC: There are no strange distortions, but music is interrupted for a half second (a time depends on a size of WASAPI buffers).

2. Transmission noise (ground loops, cheap cable). Each data frame is checked for errors. When wrong CRC is detected, frame is dropped and replaced with zero samples, it is very short time, you won't notice anything wrong.

-----------------------
TL;DR,
Losing synchronisation (effects as described) won't happen in WASAPI event mode. It is a right transfer mode for DI-20; a source data stream is always synchronised with DI-20 clock. Your options:

1. Use a good quality USB cable. When testing the cable use WASAPI push output device. Use ferrite clamps on the USB cable (it can be two on both sides of the cable) to see whether it helps. Switch to the WASAPI event output device when finished testing and always play in this mode.

2. When it is required to skip a track or reset DI-20 and your output device is WASAPI push (or some other non bit-perfect output), don't pressure Kingwa to fix firmware. Result will be detrimental to all users who have proper low-noise setup. What Kingwa will do is increase frequency range of PLL loop. PLL will stay synchronised all the time, but on the cost of increasing jitter. If you don't understand what I am saying, trust me, it will happen.

3. When it is required to skip a track or reset DI-20 and your output device is WASAPI event, then something is wrong with DI-20, your feedback is required.

 

[FredA]

Good observation, it is true due to the latency on one side, but ground loop noise is a clulprit in most cases, so a different cable can reduce effect, it may even eliminate if lucky.

On my laptop as a source it happens when synchronous transfer mode is selected, the same happens on three different DACs tested. One has Amanero drivers, second one XMOS, the third use built in Windows drivers (CM108 chip). All of them lose synchnronisation at times, producing similar distortions. A time to recover vary, depends on the chip. CM108 is the worst one.

I have a bit-perfect configuration in Foobar, so load of the system is minimal and DPC latency is in control, but it still happens when using WASAPI push mode. It indicate excess of noise on my cheap cable. When switching to the WASAPI event mode effect is different. Now there are two cases, it will help you recognise a cause:

1. DPC latency problem on PC: There are no strange distortions, but music is interrupted for a half second (a time depends on a size of WASAPI buffers).

2. Transmission noise (ground loops, cheap cable). Each data frame is checked for errors. When wrong CRC is detected, frame discarged and replaced with zero samples, it is very short time, you won't notice anything wrong.

-----------------------
TL;DR,
Losing synchronisation (effects as described) won't happen in WASAPI event mode. It is a right transfer mode for DI-20; a source data stream is always synchronised with DI-20 clock. Your options:

1. Use a good quality USB cable. When testing the cable use WASAPI push output device. Use ferrite clamps on the USB cable (it can be two on both sides of the cable) to see whether it helps. Switch to the WASAPI event output device when finished testing and always play in this mode.

2. When it is required to skip a track or reset DI-20 and your output device is WASAPI push (or some other non bit-perfect output), don't pressure Kingwa to fix firmware. Result will be detrimental to all users who have proper low-noise setup. What Kingwa will do is increase frequency range of PLL loop. PLL will stay synchronised all the time, but on the cost of increasing jitter. If you don't understand what I am saying, trust me, it will happen.

3. When it is required to skip a track or reset DI-20 and your output device is WASAPI event, then something is wrong with DI-20, your feedback is required.

Are you sure a pll is involved?

 

[sajunky]

Are you sure a pll is involved?

Yip, definitely. WASAPI push is a synchronous mode, Direct Sound output too, AFAIK. In this case PC is a source of a clock for the transfer. Receiving side has only choice to synchronise to this clock.

WASAPI event is asynchronous transfer. Only in this mode it is possible to avoid PLL and it is done first time in DI-20. See some my previous message, I insisted on using WASAPI event output in result to this change.

We need of course Kingwa to clarify this, I can be wrong.

 

[FredA]

But it the amanero talking to the PC. Kingwa does not work on the Amanero so... No possibility he will change its fw.

 

[sajunky]

But it the amanero talking to the PC. Kingwa does not work on the Amanero so... No possibility he will change its fw.

I don't understand. PLL is implemented in FPGA.

 

[FredA]

Yes. I don’t think one is used when playing from the amanero.