It seems to me that you need to do some more measurements on sample rate converters to understand and learn about their typical behaviour. This is not 'jitter', it is more 'distortion'. And I might add on a level no one cares about.

A SRC will show very different results using different clock ratios. Using internal clock at the same rate as the incoming signal there is a very small difference between the incoming and the internal clock, and depending on how many 0.x Hz that difference is the FFTs will show quite different results. Runing the SRC on the incoming clock will produce near perfect results as the ratio is 0 (note that this application is there for the science geek, not for using it in real-world - there is no application that would make sense for this specific setup).

Also a SRC IS a jitter killer. Unfortunately many people misunderstand this simple statement. If you feed the SPDIF input a jittery signal, lets say 40 ns of jitter, the SRC will remove that completely. Problem is: you don't have such a source. All the sources one has at home these days are typically without jitter, or so low it doesn't matter. Then people start to use the Julian Dunn test signal and interprete the result as 'jitter reduction', which is wrong again. That signal has no jitter and does not uncover jitter. It can only uncover flaws in the SPDIF/AES digital receiver and the clock recovery, but gives zero information how the unit handles an incoming jittery SPDIF or AES signal. For such a test the SPDIF/AES signal has to have a known amount of jitter, of more than a few ns.

I would like to check your above settings but the description of the whole setup is unclear:

> All my measurements were performed with ASIO 24/96 via XLR connection in the loopback mode.

Analog Loopback? RMAA shows the signal at the analog input?

> At the first three lines, the signal was fed to the AES input from an external digital transport (SOTM dX-USB HD). Blue line shows results of classic AES/SPDIF as master clock.

How can this workl? The SOTM can not be clocked externally, is always master, so you can not use the ADI's AES input with internal clock. Your input signal is LOCK, not SYNC.

From the below I think you mean that the ADI is set to be slave to the AES input, clock set to AES input.

> Next line (Black color) shows small artifacts above 10 kHz. It was happened when I keep AES as Master

...as clock yource...

> but turn SRC (AES-In). So the ADI works as SRC with a ratio of 0. What you see is what the SRC chip does to the signal in such a state.

> The most strange and littered output (Red line) turns out on the mode (Clock Int + SRC).

No problem, and the result is easily within the specs of the used SRC chip.

> That is, I believe this problem can be fixed in the next firmware.

So far I don't see any problem. Remember to look at the Y scale and where you are measuring.

Please clear the above questions and I will try to reproduce your measurement on my system.

No, that's what happens when you choose to sync to an external source, then the unit will run off that source. SRC converts your external signal to the internal sample rate to make it match.

Regards
Daniel Fuchs
RME

Here you can download the data sheet of the used SRC:

https://www.akm.com/akm/en/file/datasheet/AK4127VF.pdf

Correct. But, as mentioned in the manual, it won't bring any advantage. The upsampling process uses a 44.1 based filter, and the filter's response is then what you will see/measure at 176 kHz with NOS. In contrast to very flexible software SRCs like SOX, the hardware SRCs are quite limited in configuration. We have no access to any filters or other properties of the chip. Note that the SRC function is an add-on and not a major / main feature of the ADI-2 Pro.

Why did you change to another DA and AD conversion to see the SRC results, instead of checking the digital input directly?

No, here we are talking about SRC off. You can not use the SOTM with the ADI on internal clock. Only when the SRC is active.

Now you got me completely confused...