Point is that on AD1865 - "The falling edge of LL and LR cause the last 18 bits which were clocked into the Serial Registers to be shifted into the DACs, thereby updating the DAC outputs".
Look CS8414 data sheet page 22 FMT 6. If you feed FSYNC directly to LL and inverted FSYNC to RL of AD1865 you get falling edge on RL 32 cycles ( ~11.34 microseconds) (+ 16 ns inverter delay) later than on LL. That mean DAC right output will updated 32 cycles later than left.
Look also AD1865 data sheet page 7 figure 8 how Ad1865 needs data and latch signals be aligned.
Also you can think why are needed this kind of devices as: High End Audio - Digital decoder for NOS DAC
Ahhh... getting it now. You mean that data is updated asynchronous for different channels, and then yes, at output you will get some phase delay between channels. The only solution then is relocking and aligning left and right data separate (as per your link).
Another question is this audible in real world ? I highly doubt that.
Some other thoughts about approaches for feeding 1865 data inputs:
IMHO the whole point of this NOS design that we are talking about here is its simplicity. The basic idea behind this would be “minimum messing with data from source to DAC input that you can get with”. Keep it kosher as to say, that means no relocking/shifting etc. If you are worrying about jitter and other SPDIF retaliated parameters - upgrade your transport first. For me personally, SPDIF is written of long time ago, as a bungled “consumer standard”. Even though CS8416 does it’s job pretty well.
What would really contribute to this design, again IMHO, is I2S interface. Picking up I2S data directly from your source decoder, transporting it to DAC (quite problematic point), and only using some shift registers to arrange data properly for 1865 is quite tempting to tray out. This way you are omitting whole stage of muxing/demuxing already usable I2S data for SPDIF transmission. I bet there would be quite a leap of performance.
In this DAD End2 design Obbligato Premium, Jensen, OS-CON and Elna Silmic capacitors are used and you doubt that channel dalay of 11.34 microseconds is not audible ):
I think first things must be done right then simple.
Yes yes, lots of shiny&pricy things here involved, good thing that I’m only using a basically modified ZEN pre for testing purposes now
You made me took out my dusty calc from drawer and… well using 44.1k sampling, 1 sck cycle is 0.35us, so for 32 sck there is 11.34 us delay, right….
That is IF each DAC channel is updated separately, which seems to be this way, according to 1865 datasheet.
Now I have done some testing on Steinberg WaveLab. Cutting right channel of 44.1k WAV precisely 0.01ms (maximum resolution). What can I say… can’t hear any difference
That is using ESI Juli@ and HD650’s. Maybe it’s time to see my doctor In summary, yes – there is a “bug”. But is it audible ? I think everyone must decide for him self.
Audio Note digital board
If you are interested in Audio Note digital side solution it can be seen on:
http://www.audionotekits.com/dacschem.jpg
As I understand from photos also all other Audio Note DACs had same digital board with 74HC02 "converter" chip, at least until DAC 4. As on AD1865 latch signal LR is inverted LL signal, it mean also on Audio Note right channel is delayed.
If you are interested in Audio Note digital side solution it can be seen on:
http://www.audionotekits.com/dacschem.jpg
As I understand from photos also all other Audio Note DACs had same digital board with 74HC02 "converter" chip, at least until DAC 4. As on AD1865 latch signal LR is inverted LL signal, it mean also on Audio Note right channel is delayed.
Having a look at Audionote digital side solution, I agree that it is basically the same as DAC END2. Just a 2x propagation delays for data, as it is going thru HC02 gates. That’s maybe having something due to author’s worries about data being properly latched to DAC on FSYNC falling edge.
Well, I think the simplest way of solving this problem would be delaying right channel data exactly by 32 clk, and feeding FSYNC to both LL and LR. This could be accomplished by 4 x 74ACT164 8bit shift registers, without degrading data synchronization too much. These 74ACT are real fast, 6ns typ., so only 24ns delay for right channel data. If my logic is valid, all should work fine.
Or 74HCT374 as from thread: EIAJ to I2S (and vice versa)
(needed login to see attachments)
Existing also one chip 32 bit shift registers (4517 and 4557 from different producers) but they are slow, max clock about 2-6 MHz at 5V supply voltage. But who knows, maybe can also work as NOS DACs has clock about 2.882 MHz?
(needed login to see attachments)
Existing also one chip 32 bit shift registers (4517 and 4557 from different producers) but they are slow, max clock about 2-6 MHz at 5V supply voltage. But who knows, maybe can also work as NOS DACs has clock about 2.882 MHz?
I have a grounding question. I spent the weekend changing the grounding scheme and reduced hum by 75%. I floated the tube output grounds and separately the DAC board grounds. Aside from reduced hum there was a dramatic difference even in dynamics.
In getting deeper into the scheme the DAC board has analog grounds and digital grounds at input and analog at output. Do you think the analog output grounds of the dac board should go to the analog lifted grounds?
In getting deeper into the scheme the DAC board has analog grounds and digital grounds at input and analog at output. Do you think the analog output grounds of the dac board should go to the analog lifted grounds?
Don't understand what is the problem here.
CS giving 18 bit output, so AN (in all DAC's with AD1865) use only HC02 to invert one LATCH line. In this case, both channels are not latching at the same time.
Shifter can be used for latching both channels at the same time, and it was used in the first version of Rockna DAC. For EIAJ or I2S input, it can give on output 18 bit EIAJ (for AD1865). So if the shifter is used for AD1865, CS is not needed, because EIAJ/I2S from CD play can be connected directly.
CS giving 18 bit output, so AN (in all DAC's with AD1865) use only HC02 to invert one LATCH line. In this case, both channels are not latching at the same time.
Shifter can be used for latching both channels at the same time, and it was used in the first version of Rockna DAC. For EIAJ or I2S input, it can give on output 18 bit EIAJ (for AD1865). So if the shifter is used for AD1865, CS is not needed, because EIAJ/I2S from CD play can be connected directly.
That is the problem (according to kaameelis), channels not latching at the same time and creating fractional delay between L and R outputs.
Even better universal shifter. Just what I had in mind. Tested this one in MultiSim, it's 100% working. This can be used interfacing 1865 to any form of I2S, as well as aligning data from 8414. One just needs to figure out required amounts of data shifting, which depends entirely on source I2S format.
Sampler,
Your note has been copied on the other forum:
http://www.diyaudio.com/forums/digi...ersampling-no-digital-filter.html#post2175215
Your note has been copied on the other forum:
http://www.diyaudio.com/forums/digi...ersampling-no-digital-filter.html#post2175215
It's clear to me, and I wrote this.
This is the same thing, and it was published for the first time with Rockna DAC schematic. Don't understand why you need MultiSim testing because it was tested in real word and it's working OK. I tested long time ago (diyhifi.org thread) and it is working with AD1865 with EIAJ/I2S input (without CS).
Yes, there are lots of ways doing the same thing. Should work with all of them, at least with 2.822 Mhz clock for 44.1k. I would vote for ACT164, because first it's seems to be successfully tested, and second having worked with them at some point, I can confirm how quick they are. With 100Mhz analog scope, you couldn't see rising/falling edges of output signal, till some 1Mhz. Just a way I like it
Ok, I see. Didn't followed that threads, sorry....
Maybe you have a working link to Rockna DAC schematics ? Theirs site have been updated, couldn't find one.
Yes, there are lots of ways doing the same thing. Should work with all of them, at least with 2.822 Mhz clock for 44.1k. I would vote for ACT164, because first it's seems to be successfully tested, and second having worked with them at some point, I can confirm how quick they are. With 100Mhz analog scope, you couldn't see rising/falling edges of output signal, till some 1Mhz. Just a way I like it
HC164 is fast enough, and it's working OK. Anyway, faster logic can be used, but there is no need for this.
Schematic not exit on site anymore. It is attached on diyhifi.org thread, so you can find it there.
Had some spare time to play with MultiSim again. Found couple mistakes I made. First - shifting must be done for Left channel data, as it comes first in a sample, otherwise you are shifting Right channel data to other sample and in the end, have the same output delay between channels. Second - HC74 or similar flip flop must be added, to shift another 0.5 sck (thanks for the link Josiphal). This is because data is clocked from 8414 on the falling edge of sck, and HC164 locks it on rising edge of sck.
Below I will attach schematic and timing diagram for proper 8414 and 1865 interfacing. This is just my approach, could be done in a few other ways. Couple notes on this one: U2A, U2B, U2D separates data, U2C inverts latch signal. U3B, U3C 2X delays clock, as data is also 2x (or 3x if in out phase) delayed, to keep the sync. With 4XHC164 + HC74 Left data is ~39ns out of sync according to multisim. Everything else is already discussed. Again, I personally would use ALS logic, just to be on the safe side
Looked at RocknaDAC interface schematics, maybe more elegant solution using RST for data separation, but this is using 9 IC's in total
Below I will attach schematic and timing diagram for proper 8414 and 1865 interfacing. This is just my approach, could be done in a few other ways. Couple notes on this one: U2A, U2B, U2D separates data, U2C inverts latch signal. U3B, U3C 2X delays clock, as data is also 2x (or 3x if in out phase) delayed, to keep the sync. With 4XHC164 + HC74 Left data is ~39ns out of sync according to multisim. Everything else is already discussed. Again, I personally would use ALS logic, just to be on the safe side
Looked at RocknaDAC interface schematics, maybe more elegant solution using RST for data separation, but this is using 9 IC's in total
Attachments
It's interesting to calculate how much the sound travels in 11.34us: with 331m/s it travels approximately 0.37cm, so if I place my ears 0.18cm to the right it will equal the 11.34us delay. I doubt that anybody could tell the differenceYou made me took out my dusty calc from drawer and… well using 44.1k sampling, 1 sck cycle is 0.35us, so for 32 sck there is 11.34 us delay, right….
That is IF each DAC channel is updated separately, which seems to be this way, according to 1865 datasheet.
Now I have done some testing on Steinberg WaveLab. Cutting right channel of 44.1k WAV precisely 0.01ms (maximum resolution). What can I say… can’t hear any difference
In summary, yes – there is a “bug”. But is it audible ? I think everyone must decide for him self.
It's interesting to calculate how much the sound travels in 11.34us: with 331m/s it travels approximately 0.37cm, so if I place my ears 0.18cm to the right it will equal the 11.34us delay. I doubt that anybody could tell the difference
Hey, I take offense, manny of us are headphone enthusiasts. With the driver .1cm from the ear.
It's interesting to calculate how much the sound travels in 11.34us: with 331m/s it travels approximately 0.37cm, so if I place my ears 0.18cm to the right it will equal the 11.34us delay. I doubt that anybody could tell the difference
Yes, exactly, I was too lazy to do more math
But again, it would be interesting to see if there could be any improvement/degrading in sound reproduction using tube output stage and some Hi-Fi headphones. As with speakers it would be quite absurd to notice anything
For me it was just a good exercise before making I2S interface to my transport.
You might be right
thought I have to check smtg:I found this nice article about: sound perception and later today I will get a free Matlab and try to play with some wavs. I will post my findings then.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.