I have been testing an idea of synchronous reclocking whereby a computer sound card is slaved to masterclock in the DAC on PCM-63. I am using an SPDIF to I2S converter to take SPDIF out from a sound card. The receiver DIR9001 in the converter takes SPDIF via SPDIF transformer (galvanic isolation) and breaks it into 3 I2S signals. Masterclock present in this SPDIF is not used at all. At the same time the DAC’s masterclock is transmitted to SPDIF IN in the sound card via converter as SPDIF signal.
The DAC has only I2S connection with the converter and then 3 I2S signals are processed through a digital filter SM5842 and sent to the reclocking trigger whereby all 3 signals are reclocked and sent to PCM-63.
Please note that PCM-63 does not use masterclock. It only uses data, LRCK and bitclock which are reclocked by the trigger synchronised by masterclock in the DAC.
The theory states that in this case computer sound should be of the same quality as that of a CD transport.
However, there is a small problem with computer sound which is not that fast and rigorous as the sound from CD transport.
I noticed that when I use low noise PSU instead of regular 78xx in the power supply of reclocking and converter the sound improves noticeably.
But the most weird thing is that when I connected SPDIF out of the CD player to SPDIF IN of the converter then the sound improves again. This was despite the fact that when I connected CD transport to the converter the latter did not take masterclock which was contained in the SPDIF OUT of the CD transport. How can that be?
Can anyone explain this phenomenon? I can only think of the following explanation: the recloking unit can not reclock I2S signals perfectly enough and some (although reduced) level of jitter of bitclock still gets through to PCM-63. Hence I can hear some degradation of sound when I listen to computer.
One more important thing to take into account. SPDIF IN in the converter employs SPDIF transformer which galvanically isolates PC from the converter.
Also I have been experimenting with a different sound card which has only Toslink connectors. So no RF or EMI interference from PC jumps to the DAC. Again it sounds slightly worse than CD transport despite synchronous reclocking in the DAC.
How can you explain this phenomenon? I do not completely understand the theory behind synchronous reclocking. So I make a premise that despite synchronous reclocking some level of jitter still gets through. Since PCM-63 does not use masterclock then it might only be due to jitter of bitclock. I’d greatly appreciate any comments.
The DAC has only I2S connection with the converter and then 3 I2S signals are processed through a digital filter SM5842 and sent to the reclocking trigger whereby all 3 signals are reclocked and sent to PCM-63.
Please note that PCM-63 does not use masterclock. It only uses data, LRCK and bitclock which are reclocked by the trigger synchronised by masterclock in the DAC.
The theory states that in this case computer sound should be of the same quality as that of a CD transport.
However, there is a small problem with computer sound which is not that fast and rigorous as the sound from CD transport.
I noticed that when I use low noise PSU instead of regular 78xx in the power supply of reclocking and converter the sound improves noticeably.
But the most weird thing is that when I connected SPDIF out of the CD player to SPDIF IN of the converter then the sound improves again. This was despite the fact that when I connected CD transport to the converter the latter did not take masterclock which was contained in the SPDIF OUT of the CD transport. How can that be?
Can anyone explain this phenomenon? I can only think of the following explanation: the recloking unit can not reclock I2S signals perfectly enough and some (although reduced) level of jitter of bitclock still gets through to PCM-63. Hence I can hear some degradation of sound when I listen to computer.
One more important thing to take into account. SPDIF IN in the converter employs SPDIF transformer which galvanically isolates PC from the converter.
Also I have been experimenting with a different sound card which has only Toslink connectors. So no RF or EMI interference from PC jumps to the DAC. Again it sounds slightly worse than CD transport despite synchronous reclocking in the DAC.
How can you explain this phenomenon? I do not completely understand the theory behind synchronous reclocking. So I make a premise that despite synchronous reclocking some level of jitter still gets through. Since PCM-63 does not use masterclock then it might only be due to jitter of bitclock. I’d greatly appreciate any comments.
The closed clock loop synchronization approach you use does indeed have the potential to deliver minimum jitter at the DAC - if properly implemented.
One potential problem is that the reclocking signal at the DAC may need to be phase inverted relative to the 3 received I2S signals. In other words, should the reclocking instant be triggered when the I2S signals are changing it could increase rather than decrease jitter. You can verify proper reclock phasing with an oscilloscope.
Another potential problem is common-mode (ground loop) noise coupling, especially between the converter unit and the DAC unit. Supply contamination by common-mode noise can induce jitter. You mention an S/PDIF input transformer which protects that interface from power line frequency related common-mode noise. However, I suspect that the I2S interface netween the converter and DAC lack such protection. Which may be whey you find the sound to be superior without the converter, even with a synchronous closed clock loop employed. Common-mode noise protection for the I2S interface would require 3 seperate transformers at the DAC, or a balanced high CMRR I2S interface - which your converter and DAC may possibly already feature.
You really gain nothing by converting S/PDIF to I2S when utilizing a synchronous closed clock loop scheme. I suggest maintaining the closed clock loop scheme (with reclocking at the DAC) but utilize a single S/PDIF link directly connecting transport to DAC via the existing transformer coupled signal input (no I2S converter unit at all). That should provide both low clock jitter at the DAC and minimize ground loop noise induced jitter.
One potential problem is that the reclocking signal at the DAC may need to be phase inverted relative to the 3 received I2S signals. In other words, should the reclocking instant be triggered when the I2S signals are changing it could increase rather than decrease jitter. You can verify proper reclock phasing with an oscilloscope.
Another potential problem is common-mode (ground loop) noise coupling, especially between the converter unit and the DAC unit. Supply contamination by common-mode noise can induce jitter. You mention an S/PDIF input transformer which protects that interface from power line frequency related common-mode noise. However, I suspect that the I2S interface netween the converter and DAC lack such protection. Which may be whey you find the sound to be superior without the converter, even with a synchronous closed clock loop employed. Common-mode noise protection for the I2S interface would require 3 seperate transformers at the DAC, or a balanced high CMRR I2S interface - which your converter and DAC may possibly already feature.
You really gain nothing by converting S/PDIF to I2S when utilizing a synchronous closed clock loop scheme. I suggest maintaining the closed clock loop scheme (with reclocking at the DAC) but utilize a single S/PDIF link directly connecting transport to DAC via the existing transformer coupled signal input (no I2S converter unit at all). That should provide both low clock jitter at the DAC and minimize ground loop noise induced jitter.
Last edited:
I want to emphasize that when I compare the sound of a CD transport to the sound of a PC transport I connect CD transport SPDIF OUT to SPDIF IN of the converter. In other words in both instances the signal is prosessed by the converter. The converter dissects SPDIF signal into 3 I2S signals but does not take masterclock. Therefore if the signal had the wrong phase than the sound would be bad in both instances but I can clearly see that the sound is corrupted only when the convert is connected to PC transport. Please have a look at the attached image which shows schematics of the SPDIF to I2S converter.
Attachments
I know about this problem but please note the following. Again in both instances (when comparing the sound of a CD transport and PC transport via DAC) the signal goes through the converter. In both instances the signal goes as follows:
1. CD transport SPDIF OUT – SPDIF IN of the converter – SPDIF transformer in the converter – DIR9001 – 3 I2S signals to the DAC via I2S
2. PC transport: SPDIF OUT of a sound card - – SPDIF IN of the converter – SPDIF transformer in the converter – DIR9001 – 3 I2S signals to the DAC via I2S
By the way, during my experimentation I discovered that the sound is much better when I connect converter to my DAC via I2S in balanced mode (RS-485) and the I2S wires are shielded by the copper shield.
My DAC has only I2S connection. I2S connection does not have galvanic isolation but I doubt that galvanic isolation would serve any useful purpose because anyway the converter is galvanically isolated from the PC transport (PC sound card). The converter in this case is only a part of the DAC. This converter (the schematics if which is in an attached file) was designed in order to take advantage of sound cards which have SPDIF IN connectors and can be slaved to incoming clock transmitted via SPDIF IN. Frankly speaking I hardly understand the argument which you use here. In order to maintain the synchronous closed clock loop scheme we need a converter that could receive SPDIF signal and convert it into I2S as well as take masterclock from the DAC and send it to the sound card via SPDIF.
Last edited:
Only if both are likewise slaved to the DAC's masterclock. Actually, if the disc transport is not slaved the reclcoking will run asynchronously with rspect to the I2S signals, producing greater jitter than without any such reclocking. Some pepople have reported a subjective preference for this sort of asynchronous reclocking.
Last edited:
I second that. Reclock is one thing, but the ground loop or ground bounce is still there. BTW, the most important signal for PCM63 is LE. Before LE is latched, you have to make sure every channel is quiet enough for DA conversion.
If you know about common-mode noise coupling then you should recognize that your system setup is still susceptible to it. A clue is your report of the sound being better when utilizing balanced I2S between converter and DAC. Keep in mind that there are three major ground loop paths in your system, one between transport and converter, another between converter and DAC, and one between transport and DAC (passing through the converter).
While transformer coupled interfaces are very effective at rejecting lower frequency common-mode noise, they typically exhibit degrading CMRR as noise freqency rises - due to parasitic capacitance between the windings. PC switch-mode power supplies are notorious for injecting high frequency common-mode noise.
Last edited:
Now you got it right. CD transport is not slaved to the masterclock in DAC. And it can not be slaved without tinkering with the CD transport. Since it is not slaved then when we listened to CD transport we heard clicks and pops every 1 or 2 seconds. But despite that I heard that sound from CD transport was more sharp and focused than that of PC transport.
According to theory when we obtain a signal via I2S and the clock does not have to be restored then quality of wire can not change quality in any way. The only requirement is bit perfect signal. Supposedly CD transport outputs bit perfect signal and PC via ASIO is also supposed to output bit perfect signal. Who is the culprit in this case? Not good enough reclocking circuit? Or could it be that copying CD even in secure mode in EAC does not guarantee bit perfect copy? Also I read somewhere that when grabbing CD’s to hard disk it’s important to use correct offset and correct offset is important even when you just play files off the hard disk…
I want to make 2 notes here:
1. In this case TOSLINK must sound better than coaxial connection but it is not.
2. I disconnected power supply of the sound card from switch mode PSU in the PC and constructed a separate linear power supply: torroidal transformer, rectifier, capacitor, LM78xx, capacitor
Okay, I think most all is clear now. You are attempting to compare apples to oranges and yet are wondering why they would taste different. Because you subjectively prefer the sound of asynchronous reclocking doesn't mean that preference is due to it mysteriously exhibiting objectively lower jitter somehow. The reverse is most certainly the case. You have to keep in mind that the spectrum of the jitter makes a difference, just as it does for amplifier harmonic distortion. As I said before, some people prefer the sound of the jitter spectrum produced by asynchronous reclocking, despite it's objectively greater jitter magnitude. It simply becomes a matter of human perception.
Last edited:
Without objective jitter measurement there's no way to know for certain. Most likely it is due, again, simply to subjective human preference.
Also somewhere in the back of my mind I was thinking that jitter of a CD transport is not like internal jitter in syncronous reclocking systems and many people subjectively might like it more. That's why we came here. But again why on earth the sound signature of CD transport could get through the reclocking circut in the DAC?
Yes, that's what I'm saying. As long as the reclocking signal is derived from a free running masterclock at the DAC, and not from the recieved master clock embedded in the source signal.
That's just it, asynchronous reclocking does not block jitter contained in the source signal. Only synchronous reclocking does that. Source jitter will be complexly mixed with jitter produced by the asynchronous reclocking process.
Your statement about the effects of asynchronous reclocking is interesting but there’s one thing I’d like to say. The driver settings of my sound card allow me to switch on and off slaving of the card to the external clock.
From time to time I have been playing with these settings: I switched off external clock and listened to the sound. I thought that when I switched off external clock (and the card no longer was slaved to the external clock and ran on its own clock) I should hear different sound because of higher amount of jitter. However I did not notice any changes in the quality sound. Only occasionally I heard some clicks and that was all.
If you say that in asynchronous reclocking the sound changes because of higher amount of jitter that was not the case in my case. No changes at all. Only minor clicks and pops from time to time. I guess the reason for that was that the clock’s frequency in my card was very close to the frequency of the DAC’s masterclock and I only heard clicks when the digital filter in my DAC resynchronized in the moments when differences between the 2 clocks became too large. I mean I came to conclusion in this experiment that when I switched the external clock off the amount of jitter did not change at all. I mean if you call this asynchronous reclocking then you are not correct in saying that in this mode the amount of jitter increases. It does not increase because I do not hear any change in the sound.
Well, well...
> you are not correct in saying that in this mode the amount of jitter increases.
> It does not increase because I do not hear any change in the sound.
Doesn't prove anything. Some forms of jitter are very difficult to hear. Only measurements can tell.
Anyway, looking at the schematic, we have I2S coming out of DIR9001, then it is "reclocked" by a flop using the local clock. Even if the source is slaved to this local clock, the phase relationship between the local clock and the DIR9001 clock is unknown, because it depends on the delay in the whole transmission chain (SPDIF transmitter, soundcard, then receiver). It may vary depending on your hardware, soundcard configuration, cable length, temperature, etc. The whole SPDIF chain will add its jitter, of course. Anything that changes the roundtrip delay will change the phase.
Therefore signal edges can come at any time relative to the local clock. If you're very lucky, your "synchronous reclocking" might work. Otherwise, the clock edges will be too close to the I2S edges and the flop timings will be violated, resulting in large amounts of semi-random jitter. Add a bit of timing uncertainty, and you can also get bit errors with this circuit.
The result is random. This is simply not how you cross synchronized but phase unrelated clock domains. A FIFO should be used to do things cleanly.
> you are not correct in saying that in this mode the amount of jitter increases.
> It does not increase because I do not hear any change in the sound.
Doesn't prove anything. Some forms of jitter are very difficult to hear. Only measurements can tell.
Anyway, looking at the schematic, we have I2S coming out of DIR9001, then it is "reclocked" by a flop using the local clock. Even if the source is slaved to this local clock, the phase relationship between the local clock and the DIR9001 clock is unknown, because it depends on the delay in the whole transmission chain (SPDIF transmitter, soundcard, then receiver). It may vary depending on your hardware, soundcard configuration, cable length, temperature, etc. The whole SPDIF chain will add its jitter, of course. Anything that changes the roundtrip delay will change the phase.
Therefore signal edges can come at any time relative to the local clock. If you're very lucky, your "synchronous reclocking" might work. Otherwise, the clock edges will be too close to the I2S edges and the flop timings will be violated, resulting in large amounts of semi-random jitter. Add a bit of timing uncertainty, and you can also get bit errors with this circuit.
The result is random. This is simply not how you cross synchronized but phase unrelated clock domains. A FIFO should be used to do things cleanly.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.