I've never used this technique, but would presume FFT length at max (with a concommital loss of time resolution). Since this is an imprecise 'aerial view' just use consistent settings for comparative measurements for windowing, etc. Amir at Audio Science Review does this sort of measurement in his DAC reviews; there might be further info there.
ASR DAC reviews have J-test based jitter measurements only. Nothing related to phase noise measurements.
Thanks for the comment.
What setup would you recommend instead of the Cosmos ADC?
As bnilsson wanted to analyse the impact of jitter on the analog side (see post #5), I don't see how the clock in the Cosmos has any relation to the one in the DAC!? He can run the DAC at 44/16 and do a 384/24 analysis - no?
//
What he says is that other possible problem in a DAC will swamp the ones coming from clock jitter. But if your DAC has these problems (vref noise etc) you can fix these so that the clock errors show up... if you cant fix them, whats the point of measuring the clock by itself - the DAC obviously have much worse problems then its internal clock....
//
I might as well reveal why I am interested in this in the first place.
I am working on a DSP crossover for active speakers, using a Analog Devices ADSP-SC589 EZ-Board together with CCES and SigmaStudio.
A very surprising observation was that the audible impression was different when using SigmaStudio "online", downloading the DSP code to the "SS_App" framework, as opposed to exporting the SigmaStudio project DSP .h and .c files and compiling it in the standalone microcontroller project code and flash it into a bootable image for the DSP board. SigmaStudio and CCES had a better clarity and soundstage than the flashed/booted image.
To present this to Analog Devices support would have been futile, without any other argument than "it sounds different".
If I can show any measurable differences, I am in a much better situation to have it explained and possibly fixed.
Sorry about this cryptic and very brief description, but those of you who have worked with SigmaStudio may know what I refer to.
I am working on a DSP crossover for active speakers, using a Analog Devices ADSP-SC589 EZ-Board together with CCES and SigmaStudio.
A very surprising observation was that the audible impression was different when using SigmaStudio "online", downloading the DSP code to the "SS_App" framework, as opposed to exporting the SigmaStudio project DSP .h and .c files and compiling it in the standalone microcontroller project code and flash it into a bootable image for the DSP board. SigmaStudio and CCES had a better clarity and soundstage than the flashed/booted image.
To present this to Analog Devices support would have been futile, without any other argument than "it sounds different".
If I can show any measurable differences, I am in a much better situation to have it explained and possibly fixed.
Sorry about this cryptic and very brief description, but those of you who have worked with SigmaStudio may know what I refer to.
With separate clocks the phase noise seen at ADC output is not purely from DAC. And asynchronous clocks of DAC and ADC result in wide noise skirts which effectively hide most differences in these type of phase noise measurements. The differences are visible at +-10Hz around the fundamental when clocks are synchronous (as in https://www.diyaudio.com/community/attachments/ak4490_es9822pro_12k-48k-png.1069036/). With asynchronous clocks the skirts are likely at least 30dB higher at +-10Hz.
Unfortunately there are not many ADCs that support external clocks. I use my own designs (ES9822PRO & AK5394). But still you can use Cosmos ADC e.g. with J-test signals to see if there are any differences.
This ADC should support external clocks:
https://kaamostech.com/product/adc-ak5572-v2/
Thats OK... if you can setup the Cosmos in a good fashion you have a quite good analysis instrument - if you cant see anything in level, noise, frequency response or distortion in comparative measurements, I doubt you have a case - at least towards AD. Clarity and soundstage... is that really jitter... I'm not convinced as jitter causes distortion/noise, not timing errors... but this is an ever ongoing debate... perhaps "clarity" could be a case...
//
//
"With separate clocks (asynchronous?) the phase noise seen at ADC output is not purely from DAC" - isn't this ideal? (my red parenthesis)
and almost seems contradict: "With asynchronous clocks the skirts are likely at least 30dB higher at +-10Hz." - but why is this?
//
If the aim is to measure DAC (or DSP) phase noise then ADC phase noise just "adds noise" to the measurement. Why would that be ideal?
With asynchronous clocks the sampling is asynchronous (non-coherent) so the number of samples varies between bins which leads to spectral leakage and widening of noise skirts. This can be partly mitigated by using FFT windowing.
See e.g. https://www.analog.com/en/technical-articles/coherent-sampling-vs-window-sampling.html
Agreed, but I have to start somewhere. Now I can get an idea about both THD and broadening of the single tone spectrum. Actually, I have not measured anything before except FR which is always beyond what I can hear and is not an issue. The COSMOS ADC is a very good start. I understand that I cannot really measure specific "clock jitter" quantitavely with this but that's ok for now. The investment is really minimal.
Thanks, this gave me some valuable insights in the Window selection principles.
Missed the "not" - my bad 🙂
Re coherent sampling by ADC.... if I have a purely analog super oscillator to output 1kHz - which wouldn't be possible to sync to... would this mean that my ADC would do a worse job than if I produced the same stable 1kHz with a very good DAC which was synced to the DAC?
I will read the Analog pdf...
//
Could you please clarify everything that is different between the two scenarios? When using the online method, is the computer connected to the reproduction system in a different way, say, maybe with a different cable, or using an additional cable?
Also, what is the source of the audio, is it the same computer that being used for programming the DSP?
In addition, does it matter what code you load into the DSP? What if you program it for simple pass through? Still some audible difference?
Coherent sampling means that Fin/Fs is rational, i.e. number of cycles in the sampling window is integer. In practice this requires that the input frequency and sampling frequency are generated from the same clock.
Here is a tutorial on the subject:
https://www.renesas.com/us/en/docum...-coherent-and-windowed-sampling-ad-converters
Ok, I will try.
My Analog Devices ADSP-SC589 EZ-Board hardware has a SC589 processor, having one ARM core for control and two SHARC cores for DSP execution.
SigmaStudio is a piece of software from Analog Devices, where you can do symbolic programming with DSP functional modules from a toolbox/palette and draw interconnects between them.
The CCES is an Eclipse based IDE for textual programming, compiler/linker/builder. The CCES is communicating with the DSP hardware through a USB interface named ICE-1000, connected with a small flat cable at the DSP hardware side. The CCES is loading executable code through this interface in a cross compiler debug session.
When first developing the SigmaStudio project, the user starts a CCES debug session and loads a "framework" program named "Default_SS_App" into the DSP board from the CCES IDE via the ICE-1000 interface. This program is waiting for the actual DSP application code supplied by the SigmaStudio software and schematic project.
The SigmaStudio software is communicating with the running executable code and DSP hardware through another USB interface named EVAL-ADUSB2EBZ (or USBi), connected to a 10-pin header on the DSP board.
When testing the DSP schematic, the user selects "Link and Download" in the SigmaStudio software. The DSP segments are downloaded to the DSP hardware over the USBi interface, received by the "framework" program and then the DSP application runs. Any changes in parameters like parametric filters, gain modules or delay boxes are implemented on the fly. If the schematic topology is changed, the user must do a "Clean, link and download" to update the DSP code before download.
Once the SigmaStudio schematic is working satisfactory, the user can do "Export system files", and then .c and .h files are generated that contain the actual DSP code.
Now, instead of the "Default_SS_App" program, a "microcontroller" program is used. This program is (or should have) essentially the same function as the "Default_SS_App", except that it is not communicating with the SigmaStudio interface over a cable, instead the Exported DSP code is compiled in to the project. In addition, the microcontroller project code running on the ARM core can send messages to the DSP program, such as changing the input from SPDIF to USB, or changing a delay parameter, etc. Hence the name "microcontroller".
Once the microcontroller project with its embedded DSP code is compiled and built, it can be loaded and tested in a CCES debug session. If it works, a "loader" file can be generated and flashed into the ADSP-SC589 EZ-Board hardware memory, and the flashed software will boot at power-up. No interface cables need to be attached.
The problem here is that "Default_SS_App" and "mySS_uc_App" are not the same. They should perform the same task, but since the source code is not same, the execution might be different in details. The software is quite complex, and it is beyond me as an end user to figure out if and what the difference might be.
My Analog Devices ADSP-SC589 EZ-Board hardware has a SC589 processor, having one ARM core for control and two SHARC cores for DSP execution.
SigmaStudio is a piece of software from Analog Devices, where you can do symbolic programming with DSP functional modules from a toolbox/palette and draw interconnects between them.
The CCES is an Eclipse based IDE for textual programming, compiler/linker/builder. The CCES is communicating with the DSP hardware through a USB interface named ICE-1000, connected with a small flat cable at the DSP hardware side. The CCES is loading executable code through this interface in a cross compiler debug session.
When first developing the SigmaStudio project, the user starts a CCES debug session and loads a "framework" program named "Default_SS_App" into the DSP board from the CCES IDE via the ICE-1000 interface. This program is waiting for the actual DSP application code supplied by the SigmaStudio software and schematic project.
The SigmaStudio software is communicating with the running executable code and DSP hardware through another USB interface named EVAL-ADUSB2EBZ (or USBi), connected to a 10-pin header on the DSP board.
When testing the DSP schematic, the user selects "Link and Download" in the SigmaStudio software. The DSP segments are downloaded to the DSP hardware over the USBi interface, received by the "framework" program and then the DSP application runs. Any changes in parameters like parametric filters, gain modules or delay boxes are implemented on the fly. If the schematic topology is changed, the user must do a "Clean, link and download" to update the DSP code before download.
Once the SigmaStudio schematic is working satisfactory, the user can do "Export system files", and then .c and .h files are generated that contain the actual DSP code.
Now, instead of the "Default_SS_App" program, a "microcontroller" program is used. This program is (or should have) essentially the same function as the "Default_SS_App", except that it is not communicating with the SigmaStudio interface over a cable, instead the Exported DSP code is compiled in to the project. In addition, the microcontroller project code running on the ARM core can send messages to the DSP program, such as changing the input from SPDIF to USB, or changing a delay parameter, etc. Hence the name "microcontroller".
Once the microcontroller project with its embedded DSP code is compiled and built, it can be loaded and tested in a CCES debug session. If it works, a "loader" file can be generated and flashed into the ADSP-SC589 EZ-Board hardware memory, and the flashed software will boot at power-up. No interface cables need to be attached.
The problem here is that "Default_SS_App" and "mySS_uc_App" are not the same. They should perform the same task, but since the source code is not same, the execution might be different in details. The software is quite complex, and it is beyond me as an end user to figure out if and what the difference might be.
Last edited:
Hard to tell why there would be any audible differences between CCES session and flashed code. You could test with 1kHz sine or J-test output to Cosmos ADC. If the audible differences are easy to spot they should show up in measurements as well.
Phase noise is simply jitter converted from time domain to freq domain.
https://en.m.wikipedia.org/wiki/Phase_noise
Last edited: