Yes John,
The advantages of avoiding any mechanical moving parts
- no spurious PS current draws from servos & motors which bleed back into the clock PS (but logic gates firing can also cause PS glitches - so your DSP chip could also introduce some PS noise. I noticed you have avoided DSP processing as much as possible by supporting only WAV)
- no need for the error-correcting/extrapolation of real-time CD laser readers (& the associated problems)
In doing that you've addressed the main shortcomings of mechanical transports.
Your implementation of the clock signal distribution is interesting BUT I still think that you need to check the jitter at the DAC in order to prove that you have achieved your goal.
The advantages of avoiding any mechanical moving parts
- no spurious PS current draws from servos & motors which bleed back into the clock PS (but logic gates firing can also cause PS glitches - so your DSP chip could also introduce some PS noise. I noticed you have avoided DSP processing as much as possible by supporting only WAV)
- no need for the error-correcting/extrapolation of real-time CD laser readers (& the associated problems)
In doing that you've addressed the main shortcomings of mechanical transports.
Your implementation of the clock signal distribution is interesting BUT I still think that you need to check the jitter at the DAC in order to prove that you have achieved your goal.
Hi jkeny,
I attached a block diagram that may clarify the problem (cumulated jitter) and a possible solution (time correction). Best comparison would be that of feedback in an analogue circuit
I have been trying to say that sample timing jitter (DAC output) is most important parameter, low master clock jitter alone is not the solution (top block diagram). So inserting a low jitter master clock is fine, but basically provides only marginal improvement since DAC jitter contribution is usually much higher as that of the master clock, followed by flip-flops / counters and clock buffers.
Sample timing jitter (DAC output / during D/A conversion) translates to audible digital artifacts, by using selected highly critical test tracks, the effects of sample timing jitter can be magnified. Without time correction these digital artifacts remain audible. With the time correction enabled, these audible digital artifacts vanish completely.
Measuring these extreme low jitter levels is difficult (here it can only be measured at a NOS DAC unfiltered output using a suitable test signal). Modern DACs are problematic as they don't provide a suitable feedback signal (integrated switched-capacitor filters). Connecting a test probe already affects measurement too (capacitive load + introduced ground loop).
I attached a block diagram that may clarify the problem (cumulated jitter) and a possible solution (time correction). Best comparison would be that of feedback in an analogue circuit
I have been trying to say that sample timing jitter (DAC output) is most important parameter, low master clock jitter alone is not the solution (top block diagram). So inserting a low jitter master clock is fine, but basically provides only marginal improvement since DAC jitter contribution is usually much higher as that of the master clock, followed by flip-flops / counters and clock buffers.
Sample timing jitter (DAC output / during D/A conversion) translates to audible digital artifacts, by using selected highly critical test tracks, the effects of sample timing jitter can be magnified. Without time correction these digital artifacts remain audible. With the time correction enabled, these audible digital artifacts vanish completely.
Measuring these extreme low jitter levels is difficult (here it can only be measured at a NOS DAC unfiltered output using a suitable test signal). Modern DACs are problematic as they don't provide a suitable feedback signal (integrated switched-capacitor filters). Connecting a test probe already affects measurement too (capacitive load + introduced ground loop).
Attachments
mobile phone as the infra red remote control
@all:
john has designed this sd-player with respect to very low interference levels, very low jitter, etc.
following this objective, the user interface of the sd-player is very minimalistic and the user has a relatively poor gu-interface and functionality compared to a pc based media center interface.
i was wondering if somebody can write an application for mobile phones (iphone, sony-ericsson, nokia, windows mobile, symbian, ...) as "ir-remote control" for this sd-player. the application could provide an archive system with nice and attractive user and graphic interface. so by navigating through the archive on the mobile phone the user can select the desired cd and track and send just the ir-command to the sd-player.
provided the playing time (length of the tracks) is known in the database, even individual play lists can be put together by the user and stored in the cell phone.
@john:
if you provide the sd-player with a simple bi-directional ir-functionality, would this have a high negative impact on the interference and jitter levels?
if you could send some key information from the sd-player such as playing time, etc back to the ir-remote control data base (mobile phone), a very nice and accurate remote control application could be done.
cheers
mamal
@all:
john has designed this sd-player with respect to very low interference levels, very low jitter, etc.
following this objective, the user interface of the sd-player is very minimalistic and the user has a relatively poor gu-interface and functionality compared to a pc based media center interface.
i was wondering if somebody can write an application for mobile phones (iphone, sony-ericsson, nokia, windows mobile, symbian, ...) as "ir-remote control" for this sd-player. the application could provide an archive system with nice and attractive user and graphic interface. so by navigating through the archive on the mobile phone the user can select the desired cd and track and send just the ir-command to the sd-player.
provided the playing time (length of the tracks) is known in the database, even individual play lists can be put together by the user and stored in the cell phone.
@john:
if you provide the sd-player with a simple bi-directional ir-functionality, would this have a high negative impact on the interference and jitter levels?
if you could send some key information from the sd-player such as playing time, etc back to the ir-remote control data base (mobile phone), a very nice and accurate remote control application could be done.
cheers
mamal
-ecdesigns- said:
OK, you've mentioned a number of jitter reducing techniques:
-
-
- Is the time correction you now mention actually the same as the dynamic jitter attenuator?
- Can this only be done with the TDA DACs or is it applicable to others?
- Can you say what test tracks show up timing jitter clearly?
- I'm not trying to be critical here but you're very aware, I know, that changes in how a track sounds do not necessarily mean lower jitter. The sound of jitter is very elusive - are you using the test tracks from here?: http://hddaudio.net/?p=393
Aha, John, I see now where this I2S jitter reduction idea emanated from: http://www.diyaudio.com/forums/showthread.php?postid=369849#post369849
A fellow countryman of yours!
And this is where you get your jitter figure of 400 Femto secs rms!
Nobody on that thread built & measured the circuit though - have you any further info?
A fellow countryman of yours!
And this is where you get your jitter figure of 400 Femto secs rms!
Nobody on that thread built & measured the circuit though - have you any further info?
OK EC,
It seems your circuit goes beyond Henk's in that yours dynamically adjusts the timing - can you tell me the details of how this works i.e for a late BCK signal, how does the I2S circuit work to deliver this on-time?
Does it work something like: the 1.2V bias voltage moves slightly with the jitter (BCK duty cycle) & this moves the pos & neg firing point of BCK, advancing or retarding it? The trick being to get the exact correct adjustment or it introduces more jitter. How sensitive is this circuit to thermal or other drifts?
It seems your circuit goes beyond Henk's in that yours dynamically adjusts the timing - can you tell me the details of how this works i.e for a late BCK signal, how does the I2S circuit work to deliver this on-time?
Does it work something like: the 1.2V bias voltage moves slightly with the jitter (BCK duty cycle) & this moves the pos & neg firing point of BCK, advancing or retarding it? The trick being to get the exact correct adjustment or it introduces more jitter. How sensitive is this circuit to thermal or other drifts?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.