RE Integration bandwidth- Any noise or spurs above 2X the sample rate will not contribute to the output of a DAC. They don't have a way in. To some degree this is also true for LF stuff, however the pitch could be affected. So for 192 the upper end should be 384, and for 44.1 it should be 88.2.
And then there is the relationship between P-P jitter and LSB such that below a certain number its won't affect the output. Also we are usually looking at RMS phase noise. Is there any info on P-P jitter, its ratio to RMS (crest factor) and how often the peaks happen?
And then there is the relationship between P-P jitter and LSB such that below a certain number its won't affect the output. Also we are usually looking at RMS phase noise. Is there any info on P-P jitter, its ratio to RMS (crest factor) and how often the peaks happen?
Sorry this is not correct, each DAC technology (Mutlibit / SDM etc) has its own sensitive PN sweet spots and cope with PN in different ways.
There was a good AES paper wayback with simulated Jitter for various DAC architectures (hopefully someone can link to it) - these simulations demonstrated how HF Jitter at various "sensitive frequencies" folds-back into the audio B/W & degrades conversion linearity.
There was a good AES paper wayback with simulated Jitter for various DAC architectures (hopefully someone can link to it) - these simulations demonstrated how HF Jitter at various "sensitive frequencies" folds-back into the audio B/W & degrades conversion linearity.
I found a number of papers but nothing really close. Several simulation papers focusing on human thresholds but not so much on the system. "Jitter" gets 785 matches, most of which are not that relevant. AES E-Library » A Jitter Simulator on Digital Data AES E-Library » Specifying the Jitter Performance of Audio Components And this from Bruno that says specifically that a single jitter number is not adequate: AES E-Library » Effects of Jitter on AD/DA Conversion - Clock and Interface Jitter Specifications This is the closest I found and from Malcom Hawksford: AES E-Library » Jitter Simulation in High Resolution Digital Audio It still doesn't show the upper frequency folding down. Hopefully someone will find that paper.
My previous statement was based on the folding range between the clock and audio data (since if no audio then no jitter related output). I suppose some architectures could take much higher frequency components and fold them down. It would be nice to see how that works. Its helpful to think of this as a form of heterodyne radio to understand how this could work.
My previous statement was based on the folding range between the clock and audio data (since if no audio then no jitter related output). I suppose some architectures could take much higher frequency components and fold them down. It would be nice to see how that works. Its helpful to think of this as a form of heterodyne radio to understand how this could work.
Assuming that a 6 Mhz spurious is present I have several doubts that this will affect the DAC conversion.
Regardless of this I believe that the SCK coming from the Raspberry is not relevant in this investigation, because the FIFO works in a different domain, it's asynchronous, therefore it MUST NOT BE AFFECTED by the spurs from the source, otherwise the FIFO is not working properly.
So the question is: is the FIFO really source independent?
In this perspective the noise of the source does not matter, the core of the analysis is the output after the FIFO, that should be affected only by the master clock.
DIYHiFi.org • View topic - Some jitter analysis - and beating of a dead horse..
I would like to point again to this discussion.
I had been going around explicitly this problem, and in the thread there are the screenshots showing the jitter foldback. There is also an article cited, which gives a bit more insight.
Then: in that thread I have noted down some other observations:
Then:
I would like to point again to this discussion.
I had been going around explicitly this problem, and in the thread there are the screenshots showing the jitter foldback. There is also an article cited, which gives a bit more insight.
Then: in that thread I have noted down some other observations:
Then:
Then, I had shown some minutes ago the scope shots showing jitter frequency content (taken on the output of that Rotel player). It shows a great amount of jitter, no not in the 6MHz range but in the hundred kiloHertz, low megahertz range.
Then, the process to take care of this getting into the baseband, audio range is the jitter foldback..
Then, the process to take care of this getting into the baseband, audio range is the jitter foldback..
Perhaps of interest: Phase Noise Aliases as TIE Jitter | 2018-07-18 | Signal Integrity Journal
It looks like you don't get the point, unless the FIFO was source dependent, the jitter of the Raspberry is not relevant.
Please see my post #2546 and many other, the reason to use a FIFO is just to isolate the DAC from the source.
So, if the FIFO does correctly the job you don't care about the source, whatever it is.
Andrea,
What You are trying to do here is to characterize a specific tool, Ian's FiFo reclocker.
For this to execute correctly, one has to have a complete, correct assesment of the status, the signals Before the insertion of that tool, and After that tool inserted.
Not having all this right, leads to false conclusions, regarding what that DUT is really doing..
Second note: a tool such like Ian's can only remove, act on errors that are presented to it: if the jittery signal Before is principally high frequency components, it will remove that.. And the tester has to be able to quantify the effect.
Then the same tool introduces also 'secondary' effects, byproducts, like the elevated noise floor in the close in spectra. Also that is part of the analysis. A part.
You can not neglect the rest.
Ciao, George
What You are trying to do here is to characterize a specific tool, Ian's FiFo reclocker.
For this to execute correctly, one has to have a complete, correct assesment of the status, the signals Before the insertion of that tool, and After that tool inserted.
Not having all this right, leads to false conclusions, regarding what that DUT is really doing..
Second note: a tool such like Ian's can only remove, act on errors that are presented to it: if the jittery signal Before is principally high frequency components, it will remove that.. And the tester has to be able to quantify the effect.
Then the same tool introduces also 'secondary' effects, byproducts, like the elevated noise floor in the close in spectra. Also that is part of the analysis. A part.
You can not neglect the rest.
Ciao, George
I think you are wrong, you continue forgiving that they are two different domain, therefore we may care less than zero about the source.
I would buy the Fifo to be used with wathever source not with the Raspberry only. So the Raspberry or any other source are not relevant in this investigation.
As you know we are designing a pair of FIFO buffer, but we have never thought to the sources, they have to be source independent, otherwise they not do the job.
So the only output we have to care is the one from the FIFO, that's master clock dependent.
I would buy the Fifo to be used with wathever source not with the Raspberry only. So the Raspberry or any other source are not relevant in this investigation.
As you know we are designing a pair of FIFO buffer, but we have never thought to the sources, they have to be source independent, otherwise they not do the job.
So the only output we have to care is the one from the FIFO, that's master clock dependent.
Do you realise that all the data has been stored in RAM for a while before clocked out with a completely different clock than the one used to clock in the data?
//
//
6MHz happens to be a bad frequency spot for many 128FS SDM (6.144MHz) - resulting in a 144KHz offset that can fold down into the baseband... this offset also happens to be 48KHz x3, you will find every clock (and unwanted Spuire) will want to mix with each other generating a very complex "Noise" spectrum...
You need to consider the bigger picture when it comes to all clocks in the DAC architecture (including digital filters so X$, x8 are typical sensitive PN region). Harmincs of SDM master clocks (and relevant offsets) are also areas to take care.
The picture because so complex, that best practice is to care for any visible spuire, irrespective of offset.
Last edited:
"Malcom Hawksford: AES E-Library » Jitter Simulation in High Resolution Digital Audio" expands on the paper I have in mind, but not the one I'm thinking of - it might have been (I dont have AES access):-
1. The effects of sampling clock jitter on Nyquist
sampling analog-to-digital converters, and on
oversampling delta-sigma ADCs, Harris, S., JAES,
vol. 38, no. 7/8, pp. 537·542, July 1990
But you hit the nail on the head:
"Its helpful to think of this as a form of heterodyne radio to understand how this could work."
So think of every clock (SPDIF / USB input circuit, Digital OS filter, Modulator, switching regulates, MCU system clocks etc) - then image mix patterns to your hearts content - its important to remember that these clocks are not clean, and its the embedded phase noise of each and everyone of these clocks that starts the Real Fun ... OR NOT!
There are methods with modulator design where you can decorrelated spruie into wide(r) band "Noise" - its fascinating work, and one that's like opening a Russian doll, with never ending layers...
Last edited:
Was the question directed at me?
For sure the design target is clean output from a FiFo which is independent / isolated from input jitter.
UNFORTUNATELY, we live in the real world, and its NOT possible to achieve 100% isolation - we really should talk about "attenuation spectrum" or attenuation curve - digital systems are not linear in this respect... then the practicalities of isolation at an RF level comes into play...
I'd be very happy to work with Ian to expand upon his design WITHOUT uncalled for critical judgement that is being thrown around here.
Andrea,
I think John and George understand that in theory a FIFO should not be influenced by the source, but I suspect they are probably being very cautious not to be over confident that such effects are or can be fully eliminated. If spurs are not tracked down to the source, how can one be sure some stray coupling or some other unexpected mechanism is not caused by the source affecting the FIFO? Also, how could one be sure the spurs do not audibly affect dac performance regardless of their source? In my own experience, relying on standard measurements (e.g. AP tests) of dac performance is not enough to be completely sure there are no audible problems associated with spurs.
EDIT: Looks like John posted while I was still writing
I think John and George understand that in theory a FIFO should not be influenced by the source, but I suspect they are probably being very cautious not to be over confident that such effects are or can be fully eliminated. If spurs are not tracked down to the source, how can one be sure some stray coupling or some other unexpected mechanism is not caused by the source affecting the FIFO? Also, how could one be sure the spurs do not audibly affect dac performance regardless of their source? In my own experience, relying on standard measurements (e.g. AP tests) of dac performance is not enough to be completely sure there are no audible problems associated with spurs.
EDIT: Looks like John posted while I was still writing
Last edited:
If you follow Ian's threads closely there are many reports suggesting the FIFOpi performance is influenced by the Rpi. Power supply to Pi counts. Supercaps to Pi makes a difference. People have changed regulators on the Pi PCB to improve sound. And replacing the stock Pi with the Allo USBridge makes a big improvement in sound. I have experienced many of these.
I think this is consistent with other isolators on the market. I had the same kind of experience with so called SOTA reclocker/isolator for the BBB from another designer.
ecdesigns claims to that everything he tried failed in this regard and has now designed his own optical protocol which he claims gets the job done.
Last edited:
John,
if the problem is the "critical judgement" then better to close here the discussion and back to the topic of this thread.
I'm a little surprised that one can judge MSB Tech devices, discuss the Blowtorch with John Curl, the CD-77 with Thorsten Lösche, but the FifoPi is off limits.
Apparently I have not understood the spirit of this forum.
Anyway I think that is possible to achieve close to 100% isolation, that's what me and my co-developer we are working on.
I report here the way we believe, already posted in ecdesigns thread.
Assuming the DAC's switches operate on the rising edge or the falling of the LRCK, like most R2R DAC, this signal is the most crucial of the digital to analog conversion process.
So the above signal has to be as clean as possible and jitter free.
We have to not be worried about the jitter of the BCK, it does not affect the conversion, the only purpose of the BCK is to clock the shift registers of the DAC, and also we can stop the clock after data are loaded in the registers avoiding interference with the LRCK.
Since the LRCK has to be free of jitter as possible is mandatory to send it to the DAC via copper, optical isolation introduces a lot of jitter.
We need a very low phase noise master clock, that means a state of the art oscillator, to be divided down to get the right LRCK frequency depending on the sample rate family.
To do the division we need a low phase noise divider circuit, otherwise we add jitter in the division process.
To do the best, we should start from a 5/6 MHz XO, since at these frequencies we get the crystals with the higher Q as possible, that means, if well implemented, the lower phase noise as possible.
Now we have a very clean LRCK virtually free of jitter, so the DAC's switches will operate the best.
Obviously, the source (or the FIFO buffer) has to be slaved to the LRCK.
To do this in the cleanest way we have to isolate BCK and DATA signals from the DAC and from the LRCK.
Then we have to send back the LRCK to the source (or the FIFO) and also we have to feed the DAC with the above BCK and DATA.
The cleanest way is to use optic fiber cable, that is really a "brickwall" against EMI/RFI, nothing can affect this data transmission.
It's true that we are introducing a lot of jitter using the optic fiber, but as already said we can ignore this jitter because it affects only the signals that are not crucial for the conversion.
The LRCK, the only crucial signal, remains clean, it's not affected by the jitter of the other signals, so the DAC operates at its best.
This way the DAC is no longer source dependent.
Just invert LRCK with BCK, for the other DACs switching on the BCK signal, and this way works too.
The major issue is that this way is very expensive to be implemented, much more than a 100 USD device.
The strange thing is that in post #2535 I have published a pair of phase noise plots and asked a few questions, but no one answered.
Last edited:
- Status
- Not open for further replies.