Agree.
Just for myself I think 1uF NP0 would be a waste here, if you could find it (and pay for it). 1uF X7R does fine. Sure its microphonic to some extent, but we're relying on the PLL to get rid of the jitter. From what I recall of Philips CD players that I've owned in the past, they tend to use really crummy output 'transformers' which look more like inductors than transformers. I think replacing that part would be a better bet than beefing up capacitance.
Yes, use a slightly larger core to improve the LF response. But don't go for a shielded one, on that I'm totally with Jocko. There's really no useful place to connect any shield to.
Jocko? Who's Jocko?Could you guys please keep your references explicit. Or you could just exchange PMs...
This is Jocko (also known as Pat from ART) & he is talking about the Scientific Conversions transformers & noise Vs reflections (Jitter) where to buy sc947-02
He was linked to by stormsonic a few posts back. Here is the link once again:
The SB3/SPDIF output thread.......
Oh we do that too. But wouldn't you miss the didacticism?
Hi,
Jocko is a reference to the user who's handle is Jocko Homo. Knowing who is let me say that he is probably one of the few in Audio who KNOWS (as opposed to deluding himself into believing he knows) anything about SPDIF and transformers (and some other subjects).
SPDIF is pretty much dead anyway, though.
Ciao T
Jocko is a reference to the user who's handle is Jocko Homo. Knowing who is let me say that he is probably one of the few in Audio who KNOWS (as opposed to deluding himself into believing he knows) anything about SPDIF and transformers (and some other subjects).
SPDIF is pretty much dead anyway, though.
Ciao T
Hi John,
This is not true. Apply the same concepts as your SD Card Player all across, but use a FIFO and make sure you can precisely set the clock to match the source.
The results will be essentially identical.
Then it does not matter if we fill the FIFO from a hard drive, a CD Drive, an SPDIF Receiver, a USB device or even a thumb-drive. All of them are given "True Memory Playback" and locked only to your clock.
Of course, this by no means guarantees that in a complete system all sources sound the same, it only guarantees that SOURCE JITTER is not the culprit (but common mode noise, RFI etc. all still exist).
Ciao T
This is not true. Apply the same concepts as your SD Card Player all across, but use a FIFO and make sure you can precisely set the clock to match the source.
The results will be essentially identical.
Then it does not matter if we fill the FIFO from a hard drive, a CD Drive, an SPDIF Receiver, a USB device or even a thumb-drive. All of them are given "True Memory Playback" and locked only to your clock.
Of course, this by no means guarantees that in a complete system all sources sound the same, it only guarantees that SOURCE JITTER is not the culprit (but common mode noise, RFI etc. all still exist).
Ciao T
Yeah just its taking a hell of a long time to stop moving. While I can get a CD/DVD player equipped with it for 99rmb its still far and away the cheapest source solution for digital. Installed base and all that...
Yes.... more skull. Rounded edges are an indication of limited high frequency
bandwidth. Historically, oscilloscope frequency response tended to approximately follow the rule: Bandwidth x risetime = 0.35. This corresponds to a 1- or 2-pole filter roll-off in the frequency domain.
This would mean that jitter rejection from your PLL which isn't a PLL is almost perfect, right ?
Hi,
Well, there are limits to my test gear, plus the whole system after the oscillator (Reclocker, DAC etc.) adds jitter, the oscillator is not absolutely jitter free, so there comes a point where measuring anything needs silly levels of averaging on an AP2 (I once used 1024 runs on the FFT to get below the random noise of the system (including Tube analogue stage).
HOWEVER, once "locked in" you get the oscillator frequency being stepped at worst once every few minutes, the frequency step is very small (small fractions of Hz).
As there is no PLL or anything of the like, unless the MCU tells the clock system to change the frequency, it will stay at the frequency it has been set to, plus minus drift and own jitter etc, but nothing that relates to the input.
Until the input receiver unlocks it is hard to measure anything getting through (AP2 allows you to add ridiculous levels of Jitter of any kind you like, noise, sinewaves, squares, filtered as you like and so on), when the input receiver unlocks all bets are off. It unlocks at several UI of jitter, depends on jitter frequency, which is tons.
It is really the design principle the solves the "input jitter" problem and ONLY this problem. To me the challenge was to solve this problem in an "open" system, as I had already done so in a "closed" system (CD-Player).
Ciao T
Well, there are limits to my test gear, plus the whole system after the oscillator (Reclocker, DAC etc.) adds jitter, the oscillator is not absolutely jitter free, so there comes a point where measuring anything needs silly levels of averaging on an AP2 (I once used 1024 runs on the FFT to get below the random noise of the system (including Tube analogue stage).
HOWEVER, once "locked in" you get the oscillator frequency being stepped at worst once every few minutes, the frequency step is very small (small fractions of Hz).
As there is no PLL or anything of the like, unless the MCU tells the clock system to change the frequency, it will stay at the frequency it has been set to, plus minus drift and own jitter etc, but nothing that relates to the input.
Until the input receiver unlocks it is hard to measure anything getting through (AP2 allows you to add ridiculous levels of Jitter of any kind you like, noise, sinewaves, squares, filtered as you like and so on), when the input receiver unlocks all bets are off. It unlocks at several UI of jitter, depends on jitter frequency, which is tons.
It is really the design principle the solves the "input jitter" problem and ONLY this problem. To me the challenge was to solve this problem in an "open" system, as I had already done so in a "closed" system (CD-Player).
Ciao T
T, two questions:
- what happens to the sound when the signal is re-synched - burst of jitter in the sound?
- why not do this with optical & avoid CM noise, seeing as source/cable jitter doesn't matter ?
- what happens to the sound when the signal is re-synched - burst of jitter in the sound?
- why not do this with optical & avoid CM noise, seeing as source/cable jitter doesn't matter ?
Hi,
Sorry, I do not follow the question?
Re-synched? There is no such thing.
We change the clock by a very small amount, the total time variation for several clock cycles (the clock cannot change instantly) where the frequency is stepped is only picoseconds equivalent.
In the meantime the signal continues to flow through the buffer clocked by this clock.
As said, the key is to get a VERY QUICK lock onto the actual source frequency, the rest is actually not that difficult. If you cannot lock quickly you will need megabytes and megabytes of memory and you add massive delays and all...
We use input isolation with transformers. Designed in ways to isolate CM Noise . I like transformers. I understand them supremely well, know what is doable and so on. And no, I'm with Jocko on this, I'm not using SC Transformers.
Affordable optical systems have so shitty waveforms, just aesthetically they do not appeal. Expensive optical systems are better, but still I can get better results using transformers. I'm sure it is also possible to do it well using optical.
Ciao T
Sorry, I do not follow the question?
Re-synched? There is no such thing.
We change the clock by a very small amount, the total time variation for several clock cycles (the clock cannot change instantly) where the frequency is stepped is only picoseconds equivalent.
In the meantime the signal continues to flow through the buffer clocked by this clock.
As said, the key is to get a VERY QUICK lock onto the actual source frequency, the rest is actually not that difficult. If you cannot lock quickly you will need megabytes and megabytes of memory and you add massive delays and all...
We use input isolation with transformers. Designed in ways to isolate CM Noise . I like transformers. I understand them supremely well, know what is doable and so on. And no, I'm with Jocko on this, I'm not using SC Transformers.
Affordable optical systems have so shitty waveforms, just aesthetically they do not appeal. Expensive optical systems are better, but still I can get better results using transformers. I'm sure it is also possible to do it well using optical.
Ciao T
What I mean by resynch is that I presume the output clock has to match the input clock & this is done initially fairly quickly. Now as the input clock is jittery does it not mean that the input samples have been taken at the wrong time? If you ignore this & use your own local but very closely matched clock are you not doing the equivalent of asynchronous re-sampling? I presume I'm wrong here but I'm in need of help understanding!
As to optical, does it matter if the waveform is shitty - you are not using a it for clock recovery? Even SC transformers will be OK in your scenario. Again, I need some help here, understanding!
As to optical, does it matter if the waveform is shitty - you are not using a it for clock recovery? Even SC transformers will be OK in your scenario. Again, I need some help here, understanding!
Hi,
Actually, quickly AND precisely (<< 1Hz difference in tens of milliseconds on any frequency from around 44K to 192K), if we don't want to face all sorts of problems.
It's a FIFO Buffer, quite a few 100 complete samples long.
It does not matter "when" the input samples are loaded in, the only thing that does matter is that enough samples enter the buffer to keep it filled enough and that we take enough samples out to prevent overflow.
As we have many samples in the buffer we can absorb (in principle) milliseconds worth of jitter. The Output needs to be taken out at steady low jitter rate of course...
Well, kind of. I called it as working title "Asynchronous SPDIF".
Essentially, if we have two exactly identical (frequency) clocks and a FIFO in-between, then the input clock can be massively jittered, but the output jitter will depend only on the output clocks jitter.
The challenge is that we do not know the frequency of the input clock and that this clock is not really stable over long time. So if we use two discrete oscillators we eventually get enough difference accumulated to make the FIFO under- or over-flow.
Each such event creates a click, not audible on Techno or Lady Gaga, extremely annoying with a piano solo at piano (quiet) and totally freaking out the poor AP2.
So we need to make VERY SMALL adjustments to the second clock to avoid over- or under-flowing the buffer. Clearly, the more precise our clock to start with and the finer the adjustment, the longer the period before such an event is required and the smaller the change will be. In my case the adjustment steps are very small.
How we get the initial precision, sorry, that is secret, the only one. The rest is common since 80's digital comms.
I guess this is just decent engineering. Maybe overengineering.
I dislike bad waveforms in my circuits. I normally go over the whole PCB with low cap differential probes and tune the series resistors in the lines (data, clocks etc.) to give nice waveforms.
Does it matter? probably not. But seeing some of the stuff out there, the waveforms are really bad. And that can never be a good thing.
Remember, not everything is just jitter.
Ciao T
Actually, quickly AND precisely (<< 1Hz difference in tens of milliseconds on any frequency from around 44K to 192K), if we don't want to face all sorts of problems.
It's a FIFO Buffer, quite a few 100 complete samples long.
It does not matter "when" the input samples are loaded in, the only thing that does matter is that enough samples enter the buffer to keep it filled enough and that we take enough samples out to prevent overflow.
As we have many samples in the buffer we can absorb (in principle) milliseconds worth of jitter. The Output needs to be taken out at steady low jitter rate of course...
Well, kind of. I called it as working title "Asynchronous SPDIF".
Essentially, if we have two exactly identical (frequency) clocks and a FIFO in-between, then the input clock can be massively jittered, but the output jitter will depend only on the output clocks jitter.
The challenge is that we do not know the frequency of the input clock and that this clock is not really stable over long time. So if we use two discrete oscillators we eventually get enough difference accumulated to make the FIFO under- or over-flow.
Each such event creates a click, not audible on Techno or Lady Gaga, extremely annoying with a piano solo at piano (quiet) and totally freaking out the poor AP2.
So we need to make VERY SMALL adjustments to the second clock to avoid over- or under-flowing the buffer. Clearly, the more precise our clock to start with and the finer the adjustment, the longer the period before such an event is required and the smaller the change will be. In my case the adjustment steps are very small.
How we get the initial precision, sorry, that is secret, the only one. The rest is common since 80's digital comms.
I guess this is just decent engineering. Maybe overengineering.
I dislike bad waveforms in my circuits. I normally go over the whole PCB with low cap differential probes and tune the series resistors in the lines (data, clocks etc.) to give nice waveforms.
Does it matter? probably not. But seeing some of the stuff out there, the waveforms are really bad. And that can never be a good thing.
Remember, not everything is just jitter.
Ciao T
Thanks T, yes, sorry, I'm a bit slow tonight 🙂 - I was mixing up the whole clock thing between recording & playback.
Sure, that's why I asked about this as a means of trying to tease out other potential issues.
OK, that makes it clearer.
I guess you use some kind of slow multibit DAC (SPI, I²C or otherwise) to vary the control voltage on a VCXO. Since those DACs usually have a bit high noise on the output, you'd have a strong analog lowpass filtering between it and the VCXO (the design of which is probably critical). And if the source clock isn't too crappy, this DAC value should switch between two values 1 LSB apart at regular intervals, like every few minutes.
So your PLL which is not a PLL, would have an extremely low cutoff frequency, quantized frequency steps, and a very slow, intentionally limited frequency slew rate, so it doesn't try to track the source clock, but only very lazily adjust to keep the FIFO happy.
Hey, what product is that in ?
I've wanted to build something like that for a long time, maybe after I move, unpack the lab, and finish building the new house lol. Maybe not in that order though. I don't even have a decent stereo right now, too busy to listen to anything really.
> I dislike bad waveforms in my circuits.
> Does it matter? probably not.
Well, a trace with an ugly ringing waveform might (actually, will) couple into something else nearby and pollute it, so hunting for those is not just overengineering IMHO.
I guess you use some kind of slow multibit DAC (SPI, I²C or otherwise) to vary the control voltage on a VCXO. Since those DACs usually have a bit high noise on the output, you'd have a strong analog lowpass filtering between it and the VCXO (the design of which is probably critical). And if the source clock isn't too crappy, this DAC value should switch between two values 1 LSB apart at regular intervals, like every few minutes.
So your PLL which is not a PLL, would have an extremely low cutoff frequency, quantized frequency steps, and a very slow, intentionally limited frequency slew rate, so it doesn't try to track the source clock, but only very lazily adjust to keep the FIFO happy.
Hey, what product is that in ?
I've wanted to build something like that for a long time, maybe after I move, unpack the lab, and finish building the new house lol. Maybe not in that order though. I don't even have a decent stereo right now, too busy to listen to anything really.
> I dislike bad waveforms in my circuits.
> Does it matter? probably not.
Well, a trace with an ugly ringing waveform might (actually, will) couple into something else nearby and pollute it, so hunting for those is not just overengineering IMHO.
Telepathy is working... I also wanted to build something similar and a couple of hours before I explained in a long mail to a diy fellow how I would do it.
Maybe the biggest concern is not the initial precision but what Peufeu mentioned, the stability of the control voltage of the local VCXO.
Regarding the initial precision, with a fairly cheap 4K x 9 async FIFO we can buffer up to ~3.3seconds of data at 192KHz rate; taking into account the worst case scenario when the local and source clocks differ by 200ppm and we are buffering separately each channel.
A nice uController could check the half, almost-full, almost-empty signals and taking into account the used fs calculate the according voltage... If the frequencies are close enough 10-20ppm probably a small change in every minute would be enough (and this at 192KHz...)
Do you happen to know a larger (>1K) FIFO, 2 or 4bits wide and at reasonable price?
Maybe the biggest concern is not the initial precision but what Peufeu mentioned, the stability of the control voltage of the local VCXO.
Regarding the initial precision, with a fairly cheap 4K x 9 async FIFO we can buffer up to ~3.3seconds of data at 192KHz rate; taking into account the worst case scenario when the local and source clocks differ by 200ppm and we are buffering separately each channel.
A nice uController could check the half, almost-full, almost-empty signals and taking into account the used fs calculate the according voltage... If the frequencies are close enough 10-20ppm probably a small change in every minute would be enough (and this at 192KHz...)
Do you happen to know a larger (>1K) FIFO, 2 or 4bits wide and at reasonable price?
As you're already using a uC, why wouldn't you have that CPU's memory do the job of the FIFO? Its then called a ring buffer (which is how many hardware FIFOs are in practice implemented). Hardware FIFOs are fairly specialist parts (generally designed with very fast access times not necessary here) and consequently relatively expensive.
192kHz sample rate means 2x192x1000x24 bits per second = 9216000bits/s=1152000 Bytes/sec=1.1 MegaBytes/sec...
You want to keep the FIFO filled halfway to be able to compensate for + or - variations, so you will need double that ammount of memory. So it is some 2 MBytes for each second buffered (at 192kHz samplerate).
That 4k won't last more than a few milisec.
Matematica, manca-o-ar cainii...
Last edited:
You are right that a specialized 50MHz FIFO is like hunting pigeons with a cannon, but one like IDT7204L12SOG is fairly cheap ~13euro, easy to use, thus a simple PIC/Atmega uC would be enough to control. Access times would be up to 6.144MHz at 192KHz sample rate. One can probably handle this rate with a CPU but why bother with a software mode implementation if hardware FIFO is available for a good price.
- Status
- Not open for further replies.