Reclocking
Hi philpoole,
thanks for your reply [post#493]
MCK (as indicated in the universal I2S interface diagram) is the master oscillator output of the CD transport (16.9344 MHz typical), so it's higher in frequency than BCK (2.8224 MHz typical). Since timing for SPDIF is derived from this master clock by the DAC / servo chip, they have a fixed phase relation (they run in sync). By keeping SPDIF interconnection very short, jitter is already much lower than when used with the common COAX or toslink cable. So when reclocking BCK, WS and DATA with this 16.9344 MHz masterclock, you don't get the typical asynchronous reclock problems. So reclocking certainly makes sense here and can effectively reduce residual jitter on the I2S signals, regardles if they are comming directly from the DAC / servo chip or from the CS8412 outputs.
When reclocking BCK, WS and DATA (that may still contain some jitter), these can only change on the master clock transient, so they run in perfect sync with the master clock. Jitter value now only depends on the master clock stability.
So using a low jitter (external) master clock can reduce jitter even further when correctly applied.
What about I2S jitter? Is the I2S output by the transports DAC / servo chip really jitterfree? we just take it for granted it is. Reclocking it with the master clock can be revealing.
Hi philpoole,
thanks for your reply [post#493]
MCK (as indicated in the universal I2S interface diagram) is the master oscillator output of the CD transport (16.9344 MHz typical), so it's higher in frequency than BCK (2.8224 MHz typical). Since timing for SPDIF is derived from this master clock by the DAC / servo chip, they have a fixed phase relation (they run in sync). By keeping SPDIF interconnection very short, jitter is already much lower than when used with the common COAX or toslink cable. So when reclocking BCK, WS and DATA with this 16.9344 MHz masterclock, you don't get the typical asynchronous reclock problems. So reclocking certainly makes sense here and can effectively reduce residual jitter on the I2S signals, regardles if they are comming directly from the DAC / servo chip or from the CS8412 outputs.
When reclocking BCK, WS and DATA (that may still contain some jitter), these can only change on the master clock transient, so they run in perfect sync with the master clock. Jitter value now only depends on the master clock stability.
So using a low jitter (external) master clock can reduce jitter even further when correctly applied.
What about I2S jitter? Is the I2S output by the transports DAC / servo chip really jitterfree? we just take it for granted it is. Reclocking it with the master clock can be revealing.
Reclocking
Within the 304mk2 (have it from Bernard!) i modded all clock signals, and dem, they all are devided from 1 source, a 11.2896Mhz Kwak7. Yes, after some days listening, its unbelievable what an important mod this can be. The original clock outputs of dig. filter and decoder are left unused.
There still is some slight sibilance, but i will cure that. I assume a Bessel filtering could be better than the standard 3rd octave butterworth, created around opamp. Bessel has a little roll-off in highs, and better impulse handling. This time (i did in a non-os cdp) i don't want to remove the analog filter. Two beads on dac output extra could help too.
EC: what can you say about the cristal mod only, is it improved ?
Within the 304mk2 (have it from Bernard!) i modded all clock signals, and dem, they all are devided from 1 source, a 11.2896Mhz Kwak7. Yes, after some days listening, its unbelievable what an important mod this can be. The original clock outputs of dig. filter and decoder are left unused.
There still is some slight sibilance, but i will cure that. I assume a Bessel filtering could be better than the standard 3rd octave butterworth, created around opamp. Bessel has a little roll-off in highs, and better impulse handling. This time (i did in a non-os cdp) i don't want to remove the analog filter. Two beads on dac output extra could help too.
EC: what can you say about the cristal mod only, is it improved ?
Re: octal D-I DAC interface
ECD
I recommended Guido Tent's XODAC PLL for a good reason, it has
very high attenuation of SPDIF interface induced jitter from a
very low corner frequency.
Personally I run a slaved transport with master oscillator in DAC.
This is theoretically even better than I2S because the XO is -right
at the dac- reclocking all signals.
Also the interface is less important.
We also run our own design clock, but that is another story.
Cheers,
Terry
-ecdesigns- said:
ECD
I recommended Guido Tent's XODAC PLL for a good reason, it has
very high attenuation of SPDIF interface induced jitter from a
very low corner frequency.
Personally I run a slaved transport with master oscillator in DAC.
This is theoretically even better than I2S because the XO is -right
at the dac- reclocking all signals.
Also the interface is less important.
We also run our own design clock, but that is another story.
Cheers,
Terry
I don't want to hijack, so I'll keep this short:
-ecdesigns- you don't have your email address public, but I'd like to get in touch with you about your sonic resonators, if you could plz contact me, I'd really appreciate it.
in regards to this thread; it's incredibly interesting, I havent had time to read the entire thing just yet, but I'm printing it just now for my bedtime reading material.
cheers,
Daniel
PS: if you want to put me up for a few days, I'd love to come out for a listening session, can't afford to fly to the Netherlands for 8 hours, and fly back to the UK though
-ecdesigns- you don't have your email address public, but I'd like to get in touch with you about your sonic resonators, if you could plz contact me, I'd really appreciate it.
in regards to this thread; it's incredibly interesting, I havent had time to read the entire thing just yet, but I'm printing it just now for my bedtime reading material.
cheers,
Daniel
PS: if you want to put me up for a few days, I'd love to come out for a listening session, can't afford to fly to the Netherlands for 8 hours, and fly back to the UK though
repllies to posts
Hi all,
I have a lot of catching up to do with answering posts, but as I already indicated, I have been very busy lately.
weisi [post#480]
Thanks for your compliment regarding this thread, it really motivates me!
Terry Demol [post#462]
After a lot of testing, I am convinced SPDIF is not the format you want to send over a interlink, but when connecting the SPDIF receiver really close to the transport and use the differential I2S interface to run the signals across the interlink, it's a complete different story.
But I am still very interested in the transformerless differential receiver you described as it can be used for the differential I2S interface as well. However, multiple differential I2S are to be used in the octal D-I DAC to switch between various digital sources like CD player, sattelite receiver and USB from the mac. So we need many differential receivers.
cheers, John
stefanobilliani [post#469]
The balanced I2S interface is in the universal I2S interface schematics, different transmitters / receivers have to be compared for obtaining best results. Currently I am using 4 X DS8922, 70mV hysteresis, 12nS delay, 500pS skew.
Maxlorenz [post#471]
The CDPRO-2M can be connected to the universal I2S interface, problem solved. Changing taps in the timing chain can also be done, read [post#482] carefully. But then only the sony format can be used, so with multiple inputs on the octal D-I DAC using both sony and philips format you have a problem (USB interface PCM2706 uses the philips format). So I like to stick to the philips format.
a333bt [post#483]
SPDIF is no longer an issue as I now use I2S for the interlink. I don't know yet when the PCB's can be manufactured, as I still have to design and test some more modules (I2S input switch, analog output switch, system controller and power supplies). But perhaps I could already start with ordering PCB's for the analog mainboard and it's modules soon.
rfbrw [post#487]
I referred to the sony and philips format
rfbrw [post#489]
Read post #486 carefully, also have a look at the schematics. The CS8412 is soly used to get a philips format from a transport outputting the sony format. The circuit works beyond expectations, It has resulted in a major improvement that can be noticed within seconds. It's in huge contrast with the existing SPDIF interlink I used previously.
duderduderini [post#490]
Welcome to this thread, the cdmpro2 seems to use the sony format, so the universal I2S interface [post#486] can be used to convert to philips format, however I want to improve it, so there will be some modifications. I plan to provide circuit boards (also for the power supplies and tube output stages) and housing parts (if desired) for this project, however supplying electrical components is a problem due to the RoHS directive.
Hi all,
I have a lot of catching up to do with answering posts, but as I already indicated, I have been very busy lately.
weisi [post#480]
Thanks for your compliment regarding this thread, it really motivates me!
Terry Demol [post#462]
After a lot of testing, I am convinced SPDIF is not the format you want to send over a interlink, but when connecting the SPDIF receiver really close to the transport and use the differential I2S interface to run the signals across the interlink, it's a complete different story.
But I am still very interested in the transformerless differential receiver you described as it can be used for the differential I2S interface as well. However, multiple differential I2S are to be used in the octal D-I DAC to switch between various digital sources like CD player, sattelite receiver and USB from the mac. So we need many differential receivers.
cheers, John
stefanobilliani [post#469]
The balanced I2S interface is in the universal I2S interface schematics, different transmitters / receivers have to be compared for obtaining best results. Currently I am using 4 X DS8922, 70mV hysteresis, 12nS delay, 500pS skew.
Maxlorenz [post#471]
The CDPRO-2M can be connected to the universal I2S interface, problem solved. Changing taps in the timing chain can also be done, read [post#482] carefully. But then only the sony format can be used, so with multiple inputs on the octal D-I DAC using both sony and philips format you have a problem (USB interface PCM2706 uses the philips format). So I like to stick to the philips format.
a333bt [post#483]
SPDIF is no longer an issue as I now use I2S for the interlink. I don't know yet when the PCB's can be manufactured, as I still have to design and test some more modules (I2S input switch, analog output switch, system controller and power supplies). But perhaps I could already start with ordering PCB's for the analog mainboard and it's modules soon.
rfbrw [post#487]
I referred to the sony and philips format
rfbrw [post#489]
Read post #486 carefully, also have a look at the schematics. The CS8412 is soly used to get a philips format from a transport outputting the sony format. The circuit works beyond expectations, It has resulted in a major improvement that can be noticed within seconds. It's in huge contrast with the existing SPDIF interlink I used previously.
duderduderini [post#490]
Welcome to this thread, the cdmpro2 seems to use the sony format, so the universal I2S interface [post#486] can be used to convert to philips format, however I want to improve it, so there will be some modifications. I plan to provide circuit boards (also for the power supplies and tube output stages) and housing parts (if desired) for this project, however supplying electrical components is a problem due to the RoHS directive.
Hi all,
Still catching up answering posts,
tubee [post#491]
Yes if a philips format is available on the transport, the CS8412 can be left out since it is only used with transports that output the sony format. The setup using only the clock upgrade already improved sounquality, but I think it's improvement was partially covered up by the SPDIF interlink.
Bernhard [post#494]
The universal I2S setup (with or without CS8412) reclocks the I2S signals so they run in perfect sync with the master clock. If a low jitter master clock is used, and the laser-pickup circuitry only provides a digital bitstream (with or without servo jitter). Would this jitter have any effect in this setup as the I2S signals jitter now only depends on the master clock?
philpoole [post#495]
Yes mechanical servo noises can be a problem, I once compared a philips SACD1000 with my old twin DAC setup. Man that player sure was noisy, one could hear all servo activities in minute detail to a point it became very irritating. Noise increases when the laser pick-up frame touches or is firmly mounted to the metal housing, The metal housing then amplifies these vibrations. Similar problems occur with mounting harddisks. Using a setup Isolating the laser pick-up mechanism noise from the chassis could reduce servo noise quite a bit.
rfbrw [post#503]
I only used the CS8412 to obtain the philips format from my sony player, it's simple and it does the job, so what's the problem? The octal D-I DAC will have multiple inputs. Input devices may have sony or philips format, so one can integrate a complex timing-chain supporting both formats and (automatically) switch between these formats, or one could only adapt the device(s) outputting the sony format and exclusively use the philips format in the octal D-I DAC. I like the second option.
maxlorenz [post#504]
I am using 3 meters of network cable (3 twisted pairs are used), and the sound quality is way better than the existing SPDIF setup. The differential interface seems to work very well with I2S. I will do some "extreme" testing with 5, 10, 25, 50 and 75 meters to see how it affects BCK timing and sound quality. I also need to find the best differential transmitters and receivers, so some more testing has to be done.
No you're not crazy, I2S makes a world of difference, I should have used it much sooner.
Terry Demol [post#505]
I must admit I was sceptical about these clock upgrades, just like I was about using tubes. But now I heared what difference only a simple external clock module can make, I fully agree with you
I read about the slaved transport on the internet, some time ago. Very interesting, indeed it's logical to have the master clock as close to the DAC as possible to reclock the I2S signals. So basically, correct me if I'm wrong, you will have to feed the 16 MHz master clock back to the transport for it's internal servo mechanism and I2S timing. If so, won't this affect servo stability / servo noise? Transporting a 16 MHz clock across a interlink seems quite critical. But I am still very interested in how it improves sound quality.
Still catching up answering posts,
tubee [post#491]
Yes if a philips format is available on the transport, the CS8412 can be left out since it is only used with transports that output the sony format. The setup using only the clock upgrade already improved sounquality, but I think it's improvement was partially covered up by the SPDIF interlink.
Bernhard [post#494]
The universal I2S setup (with or without CS8412) reclocks the I2S signals so they run in perfect sync with the master clock. If a low jitter master clock is used, and the laser-pickup circuitry only provides a digital bitstream (with or without servo jitter). Would this jitter have any effect in this setup as the I2S signals jitter now only depends on the master clock?
philpoole [post#495]
Yes mechanical servo noises can be a problem, I once compared a philips SACD1000 with my old twin DAC setup. Man that player sure was noisy, one could hear all servo activities in minute detail to a point it became very irritating. Noise increases when the laser pick-up frame touches or is firmly mounted to the metal housing, The metal housing then amplifies these vibrations. Similar problems occur with mounting harddisks. Using a setup Isolating the laser pick-up mechanism noise from the chassis could reduce servo noise quite a bit.
rfbrw [post#503]
I only used the CS8412 to obtain the philips format from my sony player, it's simple and it does the job, so what's the problem? The octal D-I DAC will have multiple inputs. Input devices may have sony or philips format, so one can integrate a complex timing-chain supporting both formats and (automatically) switch between these formats, or one could only adapt the device(s) outputting the sony format and exclusively use the philips format in the octal D-I DAC. I like the second option.
maxlorenz [post#504]
I am using 3 meters of network cable (3 twisted pairs are used), and the sound quality is way better than the existing SPDIF setup. The differential interface seems to work very well with I2S. I will do some "extreme" testing with 5, 10, 25, 50 and 75 meters to see how it affects BCK timing and sound quality. I also need to find the best differential transmitters and receivers, so some more testing has to be done.
No you're not crazy, I2S makes a world of difference, I should have used it much sooner.
Terry Demol [post#505]
I must admit I was sceptical about these clock upgrades, just like I was about using tubes. But now I heared what difference only a simple external clock module can make, I fully agree with you
I read about the slaved transport on the internet, some time ago. Very interesting, indeed it's logical to have the master clock as close to the DAC as possible to reclock the I2S signals. So basically, correct me if I'm wrong, you will have to feed the 16 MHz master clock back to the transport for it's internal servo mechanism and I2S timing. If so, won't this affect servo stability / servo noise? Transporting a 16 MHz clock across a interlink seems quite critical. But I am still very interested in how it improves sound quality.
Listening sessions
Hi Voltaic,
Thanks for your compliments with regards to this thread, I really appreciate it.
I just added my email address, so you (and other diyaudio members) can contact me for a listening session.
I think it's important now for readers to get some feedback from people who actually listened to both the octal D-I DAC and sonic resonators.
Hi Voltaic,
Thanks for your compliments with regards to this thread, I really appreciate it.
I just added my email address, so you (and other diyaudio members) can contact me for a listening session.
I think it's important now for readers to get some feedback from people who actually listened to both the octal D-I DAC and sonic resonators.
-ecdesigns- said:
EC,
If you use the master clock in DAC and send it back to transport,
you can use std 8414 receiver chip and simply reclock right at the
DAC chip with a D flip flop.
Theoretically, with this setup there is no need to go to I2S because
the whole system is synchronous. Any jitter introduced by the SPDIF
I/face will be eliminated when reclocked by master XO at DAC chip.
It's really pretty simple, you just have to get the timing right for
D flip flop.
If I remember correctly, Guido T reclocked all the lines coming
into DAC but we just did the LE on PCM63.
The best, ie; lowest jitter setup has the master clock right at the
DAC and a very low noise separate power supply for it. I
recommend a small discrete shunt reg fed with it's own split bobbin
transformer.
Also I think you need to be careful how clock is sent back to
transport to prevent noise coupling.
Cheers,
Terry
I2S interface with master clock
Hi Terry Demol,
thanks for your reply [post#512]
I finally received the 26LS31 and 26LS32, they seem to work fine, I also did experiments using 2 differential drivers in parallell to increase output current. Since a network cable has 4 twisted pairs, I decided to add the master clock to the differential interface as well. Had some doubts if it would work (16MHz) but it did. So now we have MCK, BCK, WS and DATA on one single computer network cable.
Measurements and listening tests showed I2S also had jitter, at least on my sony transport, I already reclocked the I2S signals from the CS8412 on the transport side using 2 cascaded D-flipflops. I buffered the master clock very close to the crystal oscillator (74HC132 SMD), then I used this buffered signal for clocking the transport, D-flipflops and the differential interface. I used a thin coax cable of approx. 2.5mm diameter for making the connection from the buffer to the reclock circuit,
I also added a separate power supply for the mini crystal update based on a bandgap reference diode and a separate 12V external battery supply (only for the oscillator) as it draws little current, this should reduce master clock jitter a bit. Oscillograms show that reclocking works. I have noticed sound quality always benefits from a clean signal leaving the transport, that's why I don't like to use the SPDIF signal on the interlink anymore, even when it's reclocked in the DAC.
On the receiving side it's a different story, some jitter appears again (I now used 2.5 meters of computer network cable). Remarkable was that MCK (16 MHz) was relatively clean, I have no explanation for this yet. Using the I2S signals as they are, already greatly improved sound.
Then I decided to reclock the I2S signals again (DAC side), with MCK from the differential interface, sound again improved, and not just a bit. However, oscillograms still showed slight 2 phase jitter on BCK (similar to asynchronous reclocking). Then I only reclocked BCK (DAC side). Oscillograms now showed a stable BCK at the highest timebase setting (X10). Interference (within one chip) using these high frequencies shouldn't be underestimated. The signals surely not follow the neat diagrams drawn, they seem to have a mind of their own. So the only way to be sure is to keep measuring and listening.
The octal D-I DAC then started to show what it's capable off, seems it just needed a clean clock signal. If a setup (DAC) should be able to transmit the soul of music as maxlorenz described it [post#375], this one does, it comes over loud and clear. Sound is so smooth now, there is an abundance of crystal clear details, midrange sounds so beautiful. And I never heared bass reproduced so accurate on my set.
Problem now is, I keep pausing and scanning the same tracks to make sure wether a specific sound (that I didn't notice with the "old" setup) is actually on the CD or produced by ambient noises. Last night it seemed like a thunder storm was building-up (rumbling), so I already started to pull mains plugs (lightning strikes have destroyed equipment here twice already), then it turned out to be very deep bass sound from a CD recording (I left the CD changer playing all the time). Yes the the sound is scary realistic now.
I still have to try the setup you mentioned, putting the master clock in the DAC and feed MCK back to the transport.
But how to use multiple inputs? They might not use the same master clock frequency (sattelite receivers, USB devices). Maybe this is not clear to everybody, but I also want to use the octal D-I DAC to switch between a number of digital input sources (input selector), not only connect it to one dedicated transport. That is also the reason I don't want to change the timing chain with taps as rfbrw indicated, as the D-I system will then only be able to function correctly with either the sony or the philips format exclusively. Philips format needs all 8 taps at exactly 8BCK intervals (64), Sony format needs all 8 taps at exactly 6BCK intervals (48).
I plan to use I2S interfaces with master clock exclusively for the octal D-I DAC inputs. Devices connected to the octal D-I DAC must provide a I2S (philips format) signal together with the master clock. This can be done by using small converters close to the digital source. Screened twisted pair network cable with RJ45 connectors can be used for the interlink.
All this interface testing and clock tweaking seems to be a bit "off topic" but it's essential for the final octal D-I DAC circuitry setup, and the modules needed.
I will post schematic diagrams of the new I2S setup and the battery operated master clock soon.
cheers,
John
Hi Terry Demol,
thanks for your reply [post#512]
I finally received the 26LS31 and 26LS32, they seem to work fine, I also did experiments using 2 differential drivers in parallell to increase output current. Since a network cable has 4 twisted pairs, I decided to add the master clock to the differential interface as well. Had some doubts if it would work (16MHz) but it did. So now we have MCK, BCK, WS and DATA on one single computer network cable.
Measurements and listening tests showed I2S also had jitter, at least on my sony transport, I already reclocked the I2S signals from the CS8412 on the transport side using 2 cascaded D-flipflops. I buffered the master clock very close to the crystal oscillator (74HC132 SMD), then I used this buffered signal for clocking the transport, D-flipflops and the differential interface. I used a thin coax cable of approx. 2.5mm diameter for making the connection from the buffer to the reclock circuit,
I also added a separate power supply for the mini crystal update based on a bandgap reference diode and a separate 12V external battery supply (only for the oscillator) as it draws little current, this should reduce master clock jitter a bit. Oscillograms show that reclocking works. I have noticed sound quality always benefits from a clean signal leaving the transport, that's why I don't like to use the SPDIF signal on the interlink anymore, even when it's reclocked in the DAC.
On the receiving side it's a different story, some jitter appears again (I now used 2.5 meters of computer network cable). Remarkable was that MCK (16 MHz) was relatively clean, I have no explanation for this yet. Using the I2S signals as they are, already greatly improved sound.
Then I decided to reclock the I2S signals again (DAC side), with MCK from the differential interface, sound again improved, and not just a bit. However, oscillograms still showed slight 2 phase jitter on BCK (similar to asynchronous reclocking). Then I only reclocked BCK (DAC side). Oscillograms now showed a stable BCK at the highest timebase setting (X10). Interference (within one chip) using these high frequencies shouldn't be underestimated. The signals surely not follow the neat diagrams drawn, they seem to have a mind of their own. So the only way to be sure is to keep measuring and listening.
The octal D-I DAC then started to show what it's capable off, seems it just needed a clean clock signal. If a setup (DAC) should be able to transmit the soul of music as maxlorenz described it [post#375], this one does, it comes over loud and clear. Sound is so smooth now, there is an abundance of crystal clear details, midrange sounds so beautiful. And I never heared bass reproduced so accurate on my set.
Problem now is, I keep pausing and scanning the same tracks to make sure wether a specific sound (that I didn't notice with the "old" setup) is actually on the CD or produced by ambient noises. Last night it seemed like a thunder storm was building-up (rumbling), so I already started to pull mains plugs (lightning strikes have destroyed equipment here twice already), then it turned out to be very deep bass sound from a CD recording (I left the CD changer playing all the time). Yes the the sound is scary realistic now.
I still have to try the setup you mentioned, putting the master clock in the DAC and feed MCK back to the transport.
But how to use multiple inputs? They might not use the same master clock frequency (sattelite receivers, USB devices). Maybe this is not clear to everybody, but I also want to use the octal D-I DAC to switch between a number of digital input sources (input selector), not only connect it to one dedicated transport. That is also the reason I don't want to change the timing chain with taps as rfbrw indicated, as the D-I system will then only be able to function correctly with either the sony or the philips format exclusively. Philips format needs all 8 taps at exactly 8BCK intervals (64), Sony format needs all 8 taps at exactly 6BCK intervals (48).
I plan to use I2S interfaces with master clock exclusively for the octal D-I DAC inputs. Devices connected to the octal D-I DAC must provide a I2S (philips format) signal together with the master clock. This can be done by using small converters close to the digital source. Screened twisted pair network cable with RJ45 connectors can be used for the interlink.
All this interface testing and clock tweaking seems to be a bit "off topic" but it's essential for the final octal D-I DAC circuitry setup, and the modules needed.
I will post schematic diagrams of the new I2S setup and the battery operated master clock soon.
cheers,
John
Hi John,
(thanks for the reply on reclocking earlier)
I noticed that the foil screened cat5 cable I have is basically a bundle of twisted pairs within a shield. Might be overkill, but you could fabricate a cable (from several lengths of the above) so that each individual twisted pair is shielded. Might be useful, especially as you're running mclk next to data and bclk.
I guess your cable might already be like that.
I've almost finished the driver board (using 2x DS9638) and hope to mount it in the CDP one day soon, and my TDA1541As arrived in the post this morning
I've got all of the bits to build a basic DAC now, fed with this balanced I2S. Need to think about I/V conversion and some form of output filtering though.
Cheers,
Phil
(thanks for the reply on reclocking earlier)
I noticed that the foil screened cat5 cable I have is basically a bundle of twisted pairs within a shield. Might be overkill, but you could fabricate a cable (from several lengths of the above) so that each individual twisted pair is shielded. Might be useful, especially as you're running mclk next to data and bclk.
I guess your cable might already be like that.
I've almost finished the driver board (using 2x DS9638) and hope to mount it in the CDP one day soon, and my TDA1541As arrived in the post this morning
I've got all of the bits to build a basic DAC now, fed with this balanced I2S. Need to think about I/V conversion and some form of output filtering though.
Cheers,
Phil
Hi John:
This is a good sign, bass reproduction particular and mid-band also can profit a lot with a clean digital signal. I experienced this also on the first time i listened to my plastic non-os CD640, after installing a good clock with dividers. (some other members here think i am only elaborating the clock) But digitally OS systems can profit too, (304)
I don't think this is slight off-topic here, it still involves with improving your design, and to get it "ultimate''
How did you measure the jitter?
Hello EC designs,
I am very patient waiting, looking in my inbox email, for your invitation as you have posted earlier. Perhaps something went wrong?
->
Hi Dutchman,
Thanks for your reply [post#453]
Yes of course you can come over to listen to the DAC, I will send you an invitation by email.
When you decide to come over and listen to the octal D-I DAC and sonic resonators, you can bring your favorite CD's for comparison.
If you like the octal D-I DAC sound, you can build it of course. The octal D-I DAC core (analog mainboard), tube output stage and SPDIF audio interface could already be used."
....
I already have a CS 8412 waiting for a good job... I don't have the 1541's, but that is, I guess, no problem.
I am very patient waiting, looking in my inbox email, for your invitation as you have posted earlier. Perhaps something went wrong?
->
Hi Dutchman,
Thanks for your reply [post#453]
Yes of course you can come over to listen to the DAC, I will send you an invitation by email.
When you decide to come over and listen to the octal D-I DAC and sonic resonators, you can bring your favorite CD's for comparison.
If you like the octal D-I DAC sound, you can build it of course. The octal D-I DAC core (analog mainboard), tube output stage and SPDIF audio interface could already be used."
....
I already have a CS 8412 waiting for a good job... I don't have the 1541's, but that is, I guess, no problem.