1 (edited by dir 2018-11-12 23:14:52)

Topic: Comparing AES and INT Clock modes

I was surprised at the strange behavior of ADI-2 Pro FS when internal master clock is activated.
https://www.forum.rme-audio.de/viewtopic.php?id=27856
MС says its nothing special on his own measurement gear, so I decided to make several measurements with RMAA software. Everyone can download this program and repeat my procedure. http://audio.rightmark.org/index_new.shtml
All my measurements were performed with ASIO 24/96 via XLR connection in the loopback mode. Thus, we have eliminated possible interference with unbalanced connection.
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. A measurement shows that as  most “clean” output without any strange artifacts.
Next line (Black color) shows small artifacts above 10 kHz. It was happened when I keep AES as Master but turn SRC (AES-In). They are below 140 dB and increase the harmonic ratio only for 0.00001%, but still this is a high-frequency band so it would be better to avoid that.

http://i.piccy.info/i9/3d483195585ae9a69179add0b89ded1e/1542049628/52583/1274225/thd.png
The most strange and littered output (Red line) turns out on the mode (Clock Int + SRC). It was recommended (by RME's manual)  as the jitter killer for SPDIF connection. So we can see exactly the opposite issue! Look at symmetric peaks around the main 1 kHz were added. Also it was new artifacts in the high-frequency band over 10 kHz.
Fortunately, this disgrace is not present on USB playback (Green and Gray lines), when I play signals via USB not AES. But even in it, as the IMD and crosstalk measurements shows, there is a slight loss to compare with classic AES.

http://i.piccy.info/i9/05f228575023ae1b53e305c8494d03d3/1542049711/30840/1274225/IMD.png
http://i.piccy.info/i9/1330d2572e228ea795ce5ae722709a09/1542049954/25874/1274225/crosstalk.png

Surprisingly, the position of the master clock (Int or AES), in some incomprehensible way, also affects on output of the device even on the USB playback. For example, if you look at the scan of the lower noisefloor, some artifacts will be observed only when INT master clock was On.

http://i.piccy.info/i9/80e26b0c78e46b10f87cea45ae8d870b/1542050039/66253/1274225/noise.png

I would like to hear comments from other forum members. I believe that RME does a fantastic job for improving these projects. It seems to me that in this issue looking not like error of bad hardware, but rather a software recalculation on the DSP level. That is, I believe this problem can be fixed in the next firmware.

2

Re: Comparing AES and INT Clock modes

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.

Regards
Matthias Carstens
RME

Re: Comparing AES and INT Clock modes

Thanks for the fast reply, Matthias. I am very interested to understand the internal structure and mechanism of conversion. Initially, I planned to upsample the incoming signal from 44.1 to 176.4 and finally convert it into NOS mode. This could be done only through SPDIF. The manual mentioned the method of upsampling through the SRC and offer to compare the result by ear. It so happened that the INT mode I liked least of all in sound, so I decided to study its issue in more detail.

> Analog Loopback? RMAA shows the signal at the analog input?
Correct.
> 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.
Yes, display shows LOCK. As manual says:
14.1.2 Clock Source
Choices are Auto, INT (Internal, Master), AES, SPDIF.
27.2 The SRC (Sample Rate Converter) can be used to de-couple the clocking, allowing to use more than one clock master in a digital setup.

So what’s going on, when I feed AES input and set SRC-on and Clock to INT? Following the instructions of the manual, I understood it as a change of the master clock.
We can call it jitter or distortion, yes, the levels looks like is not is really audible, but.. I was listening all these modes and prefer classic AES connection. After that I made measurements with three special programs and they all showed that there was definitely something wrong in the INT mode.

Re: Comparing AES and INT Clock modes

dir wrote:

So what’s going on, when I feed AES input and set SRC-on and Clock to INT? Following the instructions of the manual, I understood it as a change of the master clock.

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

Regards
Daniel Fuchs
RME

5

Re: Comparing AES and INT Clock modes

Hmmm, some communication problems? As far as I understood user dir his statement was correct.

Regards
Matthias Carstens
RME

6

Re: Comparing AES and INT Clock modes

dir wrote:

Thanks for the fast reply, Matthias. I am very interested to understand the internal structure and mechanism of conversion.

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

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

dir wrote:

Initially, I planned to upsample the incoming signal from 44.1 to 176.4 and finally convert it into NOS mode. This could be done only through SPDIF.

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.

dir wrote:

> Analog Loopback? RMAA shows the signal at the analog input?
Correct.

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

dir wrote:

> How can this work? 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.

Yes, display shows LOCK. As manual says:

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.

Regards
Matthias Carstens
RME

Re: Comparing AES and INT Clock modes

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

what you mean? To try the other samplerates? First time it was a 44.1 kHz signal, so i was check it on 96 kHz.

>No, here we are talking about SRC off.

No, we are talking about SRC on + Clock INT (see the graphs)
>You can not use the SOTM with the ADI on internal clock. Only when the SRC is active.
Exactly! In my experiences the SRC is always active when i use Int Clock. When I turn off the SRC and leave Int Clock,  it will not work stable, so i didnt made measurement for these mode.

8

Re: Comparing AES and INT Clock modes

Now you got me completely confused...

Regards
Matthias Carstens
RME

Re: Comparing AES and INT Clock modes

just look at the names of the color lines
I was clearly said in the post#1: The most strange and littered output (Red line) ----> (Clock Int + SRC).

10

Re: Comparing AES and INT Clock modes

anybody can explain Clock INT + SRC mode?