Hi,
Going to use it for two TDA1541's. And i am going to connect the circuit to the decoder in my ancient cd player (SAA7210). It was all 16 bit in those days ;->
Actually, the service manual says saa7210, but in reality it is an M 4804 A 0041 LGH 8631 ???? Never found out what it is. It is one of the first players to use the 7210/7220/1541 chipset.
So two 16 bit (=4 8bit) are going to do the trick for me, but if you have more bits, you might have to use six 8 bit registers. i2s is flexible here.
I am going to use the GAL in registered mode, so all the outputs are clocked at the same time by the bitclock. It may depend on how sensitive the DAC is to the timing.. Guess it becomes more critical at oversampling (or feed two oversamplingfilters
Anyway, first i'lll try something and if it works, i'll place a post.
Greetings,
Guido
Going to use it for two TDA1541's. And i am going to connect the circuit to the decoder in my ancient cd player (SAA7210). It was all 16 bit in those days ;->
Actually, the service manual says saa7210, but in reality it is an M 4804 A 0041 LGH 8631 ???? Never found out what it is. It is one of the first players to use the 7210/7220/1541 chipset.
So two 16 bit (=4 8bit) are going to do the trick for me, but if you have more bits, you might have to use six 8 bit registers. i2s is flexible here.
I am going to use the GAL in registered mode, so all the outputs are clocked at the same time by the bitclock. It may depend on how sensitive the DAC is to the timing.. Guess it becomes more critical at oversampling (or feed two oversamplingfilters
Anyway, first i'lll try something and if it works, i'll place a post.
Greetings,
Guido
The size of the shift register varies with the length and polarity of the the frame. With the usual 32 bits per channel you need a 64 bit shift register for the +L and +R frames and a 96 bit shift register for the -L and -R frames. On semi make the MC14562 dual 128 bit shift register with taps at 32 bit intervals in a 14pin dil package.
ray.
ray.
Thanks for the hint with the 4562. At 44.1 kHz with 32 bit frames, the clock will run at 2.8 MHz which is too much for a CMOS part at 5V. It may be necessary to run it at 10 or 15V and use level shifters.
There is a 4557 64 bit variable length register. Philips makes a metal gate version HEF4557BP that is a little faster.
Anybody looked into the 74HC40105 4 bit x 16 FIFO? Might be a complicated way to solve the problem at hand, but one could implement some jitter attenuation.
Eric
There is a 4557 64 bit variable length register. Philips makes a metal gate version HEF4557BP that is a little faster.
Anybody looked into the 74HC40105 4 bit x 16 FIFO? Might be a complicated way to solve the problem at hand, but one could implement some jitter attenuation.
Eric
Ok, ok,
This is my idea:
The WS signal tells the DAC when the new sample starts and when the second frame in the sample starts for the other channel.
Don't know by heart if left or right is first in and if WS if first high or low. Sorted this at home, but suppose it is like this:
I took 8 bit as example:
WS 1111111100000000
data LLLLLLLL RRRRRRRR
If we now invert WS, the DAC thinks the frame starts when the right channel is on the dataline, we can clock this into the right DAC:
WS 0000000011111111
data RRRRRRRR
So when WS changes to 1, we need also the left channel, but the first bit was there 16 clocktimes earlier. So I use a 16 bit shiftregister to delay it 16 clocktimes (output 7210 is 16 bit).
WS 0000000011111111
dataR RRRRRRRR
dataL LLLLLLLL
For the second frame of the sample, we need to have both frames delayed. But right is on the incoming dataline and is going into the same shiftregister as the left frame earlier. So we can use the output from the shiftregister again, but now the output should go to dataR. The left channel is delayed again by a second 16 bit shiftregister.
WS 000000001111111100000000
dataR RRRRRRRRRRRRRRRR
dataL LLLLLLLL LLLLLLLL
The GAL now sorts out when to put the 3 incoming datastreams (reall-time, 16 bit delayed and 32 bit delayed) on the lines dataR and dataL. Also using registered mode, so the output I2S is clocked (by the inverted incoming clock). So all the incoming signals have half the clocktime to settle.
And i have three mode-pins defined, for some extra features:
- Mute: dataR and dataL to zero
- Invert phase: dataR and dataL are the inverted from the
inputdata
- Differential: the second frame in the sample is inverted, so you
can use the DAC in balanced mode!
Easy with a GAL, just some programming.
Without the extra features, she circuit can be build with only some logic!
So 1 GAL and two 16 bit shift registers. I am going to use a 20V8 GAL for testing and 74HCT166 shiftregisters. I have these lying around, that's why. For higher bitrates, the 16 bit shifregisters can be changed for 24 bit or so. It should still work.
Going to try the above in the near future, keep you posted.
Any holes in my story ??
Greetings,
Guido
This is my idea:
The WS signal tells the DAC when the new sample starts and when the second frame in the sample starts for the other channel.
Don't know by heart if left or right is first in and if WS if first high or low. Sorted this at home, but suppose it is like this:
I took 8 bit as example:
WS 1111111100000000
data LLLLLLLL RRRRRRRR
If we now invert WS, the DAC thinks the frame starts when the right channel is on the dataline, we can clock this into the right DAC:
WS 0000000011111111
data RRRRRRRR
So when WS changes to 1, we need also the left channel, but the first bit was there 16 clocktimes earlier. So I use a 16 bit shiftregister to delay it 16 clocktimes (output 7210 is 16 bit).
WS 0000000011111111
dataR RRRRRRRR
dataL LLLLLLLL
For the second frame of the sample, we need to have both frames delayed. But right is on the incoming dataline and is going into the same shiftregister as the left frame earlier. So we can use the output from the shiftregister again, but now the output should go to dataR. The left channel is delayed again by a second 16 bit shiftregister.
WS 000000001111111100000000
dataR RRRRRRRRRRRRRRRR
dataL LLLLLLLL LLLLLLLL
The GAL now sorts out when to put the 3 incoming datastreams (reall-time, 16 bit delayed and 32 bit delayed) on the lines dataR and dataL. Also using registered mode, so the output I2S is clocked (by the inverted incoming clock). So all the incoming signals have half the clocktime to settle.
And i have three mode-pins defined, for some extra features:
- Mute: dataR and dataL to zero
- Invert phase: dataR and dataL are the inverted from the
inputdata
- Differential: the second frame in the sample is inverted, so you
can use the DAC in balanced mode!
Easy with a GAL, just some programming.
Without the extra features, she circuit can be build with only some logic!
So 1 GAL and two 16 bit shift registers. I am going to use a 20V8 GAL for testing and 74HCT166 shiftregisters. I have these lying around, that's why. For higher bitrates, the 16 bit shifregisters can be changed for 24 bit or so. It should still work.
Going to try the above in the near future, keep you posted.
Any holes in my story ??
Greetings,
Guido
Mmm,
I doesn't look like i intended, so load the text in an editor and
the timing-examples should look like this:
First: OK
Second: the datasignal RRRRRRRR should start under at the first 1 of the WS signal.
Third: both datasignals should start when WS changes from 0 to 1.
Fourth: both datasignals should start when WS changes from 0 to 1.
Hope this makes more sence.
Greetings,
Guido
I doesn't look like i intended, so load the text in an editor and
the timing-examples should look like this:
First: OK
Second: the datasignal RRRRRRRR should start under at the first 1 of the WS signal.
Third: both datasignals should start when WS changes from 0 to 1.
Fourth: both datasignals should start when WS changes from 0 to 1.
Hope this makes more sence.
Greetings,
Guido
Petter
I am not going to start a discusson here on which DAC is best, new old, non-os or os, 16 bit or 24 bit. Have some 1541's lying around and some people think old does not mean bad. But the I2S spec used nowadays for nearly all dacs does not specify the number of bits to be fixed to 16.
So the above works for 16, 18, 24 or more bits. The only change needed is that the shiftregisters should be adapted to this.
If the TDA was 24 bits, i would use 6 '166 registers to get two times 24 bit delay.
Therefore it might also be revant for the dac, the post was started for. I read that it can be configured to do all of the above internally by programming it with a serial port. If i was building a dac with two of those AD's, i would use that anyway. It would mean that only 1 chip is needed (pic-micro or so) and not 5.
I'll stop now poluting this thread and post a new one if there is new development.
Guido
I am not going to start a discusson here on which DAC is best, new old, non-os or os, 16 bit or 24 bit. Have some 1541's lying around and some people think old does not mean bad. But the I2S spec used nowadays for nearly all dacs does not specify the number of bits to be fixed to 16.
So the above works for 16, 18, 24 or more bits. The only change needed is that the shiftregisters should be adapted to this.
If the TDA was 24 bits, i would use 6 '166 registers to get two times 24 bit delay.
Therefore it might also be revant for the dac, the post was started for. I read that it can be configured to do all of the above internally by programming it with a serial port. If i was building a dac with two of those AD's, i would use that anyway. It would mean that only 1 chip is needed (pic-micro or so) and not 5.
I'll stop now poluting this thread and post a new one if there is new development.
Guido
While this is far from laying the issue to rest, here is an encouraging Q&A from an Analog engineer:Petter said:
Q. Could you comment on the relationship between IREF and the AD1853's THD and S/N figures as IREF is decreased from 1mA? The datasheet indicates attenuation to -50dB is possible via this method, but how much attenuation is possible before a significant increase in THD or S/N?
A. I have no actual data on this. Theoretically, as the bias current is decreased, the THD will improve somewhat as the current sources stay more in their linear region and for every 6dB decrease in gain the DNR will go down (get worse) by 3dB (the noise will decrease by 3dB). Referenced to full scale, the SNR will appear to improve by 3dB (limited by I/V noise).
------------
This was pretty much what I was hoping to hear.
Hi,
Just to shoot at my own post. I did not work as i thought it would. Guess Ray (and others) already knew. A sample for one channel is 32 bit long, only the first 16 bit are used. Actually the MSB does not start at WS change, bit one clock periode later. I should read the datasheets better (that is, look at the correct picture)......
So i need two 32 bit registers. I have plenty of '166 lying around, so i'll 'piggy pack' four on top of the existing ones and create extra delay. Guess it all depends on the source. Could be that a 24 bit design also uses 32 bit for one sample, with 8 bits not used. Still a matter of putting in the correct delay.
Worse is that the MSB is shifted: it means using WS to control the differential output is not possible. The other features-pins i have in mind (mute:data=0 and phase inv: dataout=-datain) should work. But they are not important, the differential output is (to me).
I'll get there.
Greetings,
Guido
Just to shoot at my own post. I did not work as i thought it would. Guess Ray (and others) already knew. A sample for one channel is 32 bit long, only the first 16 bit are used. Actually the MSB does not start at WS change, bit one clock periode later. I should read the datasheets better (that is, look at the correct picture)......
So i need two 32 bit registers. I have plenty of '166 lying around, so i'll 'piggy pack' four on top of the existing ones and create extra delay. Guess it all depends on the source. Could be that a 24 bit design also uses 32 bit for one sample, with 8 bits not used. Still a matter of putting in the correct delay.
Worse is that the MSB is shifted: it means using WS to control the differential output is not possible. The other features-pins i have in mind (mute:data=0 and phase inv: dataout=-datain) should work. But they are not important, the differential output is (to me).
I'll get there.
Greetings,
Guido
Good news on Iref -> Better news on Iref
Not stricly a layout issue
"THD will improve somewhat as the current sources stay more in their linear region"
And the answer makes me wonder whether an external Iref current source might not be the way to go for all existing and future designs.
This of course assumes that "current sources" that should stay in more linear region(s) mean those "tied" to Iref and not simply referenced to it. I asked an AD application engineer about this about 3-4 years ago (right after the 1853 was released) and his comments were that the internal voltage source (driving the external Iref resistor thus generationg Iref) was fairly good and he suspected this would not have much effect.
It would be interesting to try this out. Have you considered setting up external current source which is switchable?
Petter
Not stricly a layout issue
"THD will improve somewhat as the current sources stay more in their linear region"
And the answer makes me wonder whether an external Iref current source might not be the way to go for all existing and future designs.
This of course assumes that "current sources" that should stay in more linear region(s) mean those "tied" to Iref and not simply referenced to it. I asked an AD application engineer about this about 3-4 years ago (right after the 1853 was released) and his comments were that the internal voltage source (driving the external Iref resistor thus generationg Iref) was fairly good and he suspected this would not have much effect.
It would be interesting to try this out. Have you considered setting up external current source which is switchable?
Petter
Guido,
You need to think frames. Sticking solely with 32bit per channel frames, I2S or otherwise, creating +L/-L and +R/-R datastreams is relatively simple.
You have two shift registers one 64bits long the other 96bits both with taps every 32bits. Normal L/R data is fed to the 64bit shift register and inverted data is fed to the 96bit shift register. After 64 sclk cycles or 1 lrclk cycle the left channel data occupies bits 33 to 64 and the right channel data occupies bits 1 to 32 of the shift register and the same goes for the inverted datastream. Now when lrclk is low the left channel 2 to 1 demultiplexer selects the 64bit tap of the 64bit shift register for normal left data and the right channel demux selects the 32bit tap of the 64bit shift register for normal right channel data. While the L and R datstreams were being clocked out via the demux, the the inverted datastream was moving from bits 0 to 64 of the 96bit shift register to bits 33 to 96 of the shift register and when lrclk goes high the left channel demux now selects the 96bit tap for inverted left channel data and right channel demux the 64 bit tap for the inverted right channel data.
You might also wish to reconsider the use of a FPGA as it would allow you to do the +1 addition associated with 2's comp inversion without creating a pcb the size of a sheet of A4 paper.
ray
You need to think frames. Sticking solely with 32bit per channel frames, I2S or otherwise, creating +L/-L and +R/-R datastreams is relatively simple.
You have two shift registers one 64bits long the other 96bits both with taps every 32bits. Normal L/R data is fed to the 64bit shift register and inverted data is fed to the 96bit shift register. After 64 sclk cycles or 1 lrclk cycle the left channel data occupies bits 33 to 64 and the right channel data occupies bits 1 to 32 of the shift register and the same goes for the inverted datastream. Now when lrclk is low the left channel 2 to 1 demultiplexer selects the 64bit tap of the 64bit shift register for normal left data and the right channel demux selects the 32bit tap of the 64bit shift register for normal right channel data. While the L and R datstreams were being clocked out via the demux, the the inverted datastream was moving from bits 0 to 64 of the 96bit shift register to bits 33 to 96 of the shift register and when lrclk goes high the left channel demux now selects the 96bit tap for inverted left channel data and right channel demux the 64 bit tap for the inverted right channel data.
You might also wish to reconsider the use of a FPGA as it would allow you to do the +1 addition associated with 2's comp inversion without creating a pcb the size of a sheet of A4 paper.
ray
Tiroth (or whoever can answer these questions):
I've read your thread, and I'm interested pending more information. Since I'm a little slow on the jargon (and new to the forum), can you help me out by walking me through what this DAC is designed to be used for (I'm assuming DVD and/or DVD Audio if you are going for the 192kHz sampling rate) and how it can interface with devices?
Thanks.
I've read your thread, and I'm interested pending more information. Since I'm a little slow on the jargon (and new to the forum), can you help me out by walking me through what this DAC is designed to be used for (I'm assuming DVD and/or DVD Audio if you are going for the 192kHz sampling rate) and how it can interface with devices?
Thanks.
For Tiroth ...
Asynchronous Sample Sate Converter (SRC): Take just about any input and resamples it in the digital domain to (in this case) 24 bit/192KHz, probably doing some digital filtering in the process. Thus the DAC can be used with CD's at this sampling rate. There have been significant advance in SRC's and as usual Tiroth is using the best available. Some people like this approach (loosely coupled) others prefer a digital filter which essentially does the same thing. Me, I don't know, but I do like "exact" approaches indicating oversampling digital filter ... The good thing about an SRC is that you more or less become independent of input signal clock rate -- as we all know 48KHz (and then multiples) were specifically chosen to be hard to convert to/from 44.1KHz by the recording industry.
Inputs: For these first boards, only S/PDIF input which is the standard input for DAC's
For the full version also ADAT which is up to 8 channels at up to 48KHz. ADAT is a "professional" musician type of connection used by many "pro" sound cards. As we all know, multiple S/PDIF's are not usually catered for.
This DAC is designed for pretty much any digital input (probably limited to 96KHz using current input receiver but that is an anomaly of this chip alone). You could interface to whatever you want, but for now it is only 2 channels.
There is some pretty serious work going down on this thread.
Petter
Asynchronous Sample Sate Converter (SRC): Take just about any input and resamples it in the digital domain to (in this case) 24 bit/192KHz, probably doing some digital filtering in the process. Thus the DAC can be used with CD's at this sampling rate. There have been significant advance in SRC's and as usual Tiroth is using the best available. Some people like this approach (loosely coupled) others prefer a digital filter which essentially does the same thing. Me, I don't know, but I do like "exact" approaches indicating oversampling digital filter ... The good thing about an SRC is that you more or less become independent of input signal clock rate -- as we all know 48KHz (and then multiples) were specifically chosen to be hard to convert to/from 44.1KHz by the recording industry.
Inputs: For these first boards, only S/PDIF input which is the standard input for DAC's
For the full version also ADAT which is up to 8 channels at up to 48KHz. ADAT is a "professional" musician type of connection used by many "pro" sound cards. As we all know, multiple S/PDIF's are not usually catered for.
This DAC is designed for pretty much any digital input (probably limited to 96KHz using current input receiver but that is an anomaly of this chip alone). You could interface to whatever you want, but for now it is only 2 channels.
There is some pretty serious work going down on this thread.
Petter
DAC
Happy New year to everyone here
Hi, ttako Hi,
special thanks for the interest! I'm not so competent in digital audio as some people here, neither I can accept their super-state-of-the-art constructions etc. I've just build an external DAC for CD/MD/HDCD playback /yet used only with CD's/ with no such special constructions as special discrette DC - regs etc. But with features like several voltage regulators /78xx/79xx, LM317 types/ and over 10000-20000uF of PS capacitance and bypassing, some kind of "good layout", at least according to me, and good IC's - AD1892, AD1852 and OPA2134. The sound is excellent, compared to cheap and not so cheap CD - players. But it is possible to go much further!
Doubling AD1852 gives improvement in S/N ratio of about 3-4 dB, up to 117 dB, acc. to datasheet. For 16 to 20 bit data source, there is no use of doing this, except the design becomes more expensive by $15-20. This is my oppinion!! The AD1852 itself is good enough for CD players and is easy to use!
I don't sell anything, but if you want we can think about sending you a PCB, which I can produce here! Can you produce such somewhere around you?? The designs are in Protel format, but I don't tend to spread the design over the net that easy
I think I can send you pdf files of the PCB for preview, but this will be possible somewhere in the future, at least after 2-3 weeks
So, what system do you have/wish to up-grade, and where are you from, ttako?? Can you send me e-mail ??
best regards,
Kaloyan Mahinow
Happy New year to everyone here
Hi, ttako Hi,
special thanks for the interest! I'm not so competent in digital audio as some people here, neither I can accept their super-state-of-the-art constructions etc. I've just build an external DAC for CD/MD/HDCD playback /yet used only with CD's/ with no such special constructions as special discrette DC - regs etc. But with features like several voltage regulators /78xx/79xx, LM317 types/ and over 10000-20000uF of PS capacitance and bypassing, some kind of "good layout", at least according to me, and good IC's - AD1892, AD1852 and OPA2134. The sound is excellent, compared to cheap and not so cheap CD - players. But it is possible to go much further!
Doubling AD1852 gives improvement in S/N ratio of about 3-4 dB, up to 117 dB, acc. to datasheet. For 16 to 20 bit data source, there is no use of doing this, except the design becomes more expensive by $15-20. This is my oppinion!! The AD1852 itself is good enough for CD players and is easy to use!
I don't sell anything, but if you want we can think about sending you a PCB, which I can produce here! Can you produce such somewhere around you?? The designs are in Protel format, but I don't tend to spread the design over the net that easy
I think I can send you pdf files of the PCB for preview, but this will be possible somewhere in the future, at least after 2-3 weeks
So, what system do you have/wish to up-grade, and where are you from, ttako?? Can you send me e-mail ??
best regards,
Kaloyan Mahinow
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.