Were you ever able to discuss JA’s jitter measurements with him?
Specifically his comments: "I obtained anomalous results when I tested the PS Audio DirectStream’s rejection of wordclock jitter. Fig.13 shows a narrowband analysis of the processor’s output while it decoded 16-bit J-Test data. While the central spike that represents the high-level tone at 11.025kHz is superbly well defined, the noise floor is closer to the 15- rather than the 16-bit level. In addition, while the odd-order harmonics of the low-frequency, LSB-level squarewave decay correctly with increasing frequency, they are all higher than their correct level (green line). With 24-bit J-Test data (fig.14), the noise floor remains too high in level, though no harmonics can now be seen."
I do note his measurements were performed on a much earlier DS firmware though.
Is this something that you’ve improved (FPGA jitter rejection) with later DS firmware updates?
All black magic to me, although I love reading about this stuff.
Another presentation of jitter measurements that I’ve seen reported (not DS, something else) are shown below. Apparently the thickness of the trace is due to jitter (so, the thinner the better).
There are multiple things going on. When JA did the measurements he was using DS software that was measurably noisier than current software and that had some low level distortions. (He remeasured it again later https://www.stereophile.com/content/new-firmware-measurements)
Anyway in his original analysis he was confusing noise with resolution, which is ironic because he also complained about signals well below the noise floor (e.g. the low level linearity tests and tests on signals at -120dB) Most of his tests aren’t easy to do correctly in the presence of noise, e.g. noise could easily mask the width of the bottom of the jitter test.
Here’s the theoretically perfect test tone I generated with Dunn’s original formula:
They match within a fraction of a dB (I don’t know why JA’s weren’t level matched.) The theoretical plot I gave used 65536 points in it’s FFT and the scope I’m using uses 1048576 points for the FFT so my peaks should be 16 times narrower. There are no extra peaks within the measurement granularity of my scope:
Hence there is no measurable jitter within the resolution of my tools (the plot is about 4.8Hz per bin.)
All of this is beside the point - the J-Test can’t measure the jitter of the DS - it assumes jitter comes from anomalies in the AES3 datastream and that that noise will affect the AES decoder (the clock and data separator.) The DS doesn’t use the recovered clock from any input in any manner - it just pattern matches the data and dumps the decoded data in a buffer. To measure the jitter properly would require a crystal with lower near term phase noise than the one the DS uses (pretty hard to find) and the DS would need to be probed right at the reclocker.
Put simply: there is no measurable transfer of input jitter to the analog output. The jitter I talk about is the jitter and noise generated by the FPGA, power supplies, etc. that leaks thru the reclocker or into the analog output. That noise swamps any jitter influence.
I should have said that you shouldn’t compare my J-Test plots to other devices, my scope doesn’t have the range I would need for doing a the job properly so my test signal is lower than it should be. But it has the values changing by the requisite least significant bit at the correct rate so the levels of the peaks are legitimate which addresses JA’s level remark and as I mentioned the can’t be revealing in the case of the DS anyway. FWIW it’s the FFT windowing itself that makes the measured peaks as wide as they are, not the DS - I just didn’t want to sample a lot slower for a lot longer to show narrower peaks (it took long enough to generate those above.)
PS Audio has multiple Audio Precisions - they can do great measurement of most things.
I have an 8 bit 250MHz scope and a low noise 16 bit 5 MHz scope, both can do averaging to get about another 4 bits of effective precision or use FFTs and averaging to get more. Usually I can get close to the Audio Precision, but my environment is a little nosier (everything sharing USB, for example.) I do whatever measurements I can or want while developing and have PS Audio check the ones that I can’t do or don’t know if I’m doing well - e.g. the Audio Precision has a CD deemphasis test built in so it’s much easier for them to verify that I haven’t broken the deemphasis code.
Yes, for digital I write my own stuff in whatever language is most expedient and I have a reasonable set of programs for testing, analysis, mathematics, a Spice simulator, etc.
I sure wouldn’t mind a great 1Gig scope so I could do jitter measurements, etc. but they are extremely expensive.
Ted: Pal up with this guy… it’s like bullet time in the matrix! I timestamped it to ~40mins – showing squarewave leading edges 10ps per division in realtime!
Hi again Ted, regarded what I’ve quoted here - is this basically RF and ground leakage currents that are “generated by the FPGA, power supplies, etc. that leaks thru the reclocker or into the analog output”? …that swamps any input jitter?
Cheers @tedsmith . Seems to be a common comment among a few of the world’s better DAC designers, that mains borne RF and ground currents may (system dependant) have a bigger effect on the analogue output than input jitter - that is, for those designers like yourself that have input jitter well sorted.
Once again brings out the beauty of optical inputs. It still leaves the FPGA generated RF but eliminates input and mains related RF and ground / leakage currents.
Of course your TSS DAC will isolate all of the above nasties with the fiber optic connection between digital and analogue boxes. And you’ll pay close attention to isolating the mains power connection of the analogue box?
No, I’m afraid not. But it is differential and with a wide common mode so common mode noise is rejected fairly well. Also HDMI cables are designed for high bandwidth signals unlike, say digital RCA cables, etc.
I timestamped it to ~40mins – showing squarewave leading edges 10ps per division in realtime!