Why do you have to recover the clock from the spdif stream ?
Why can't the sample data bits be extracted from the sub-frame, sent to the dac, followed by a 'latch enable' triggered by the detection of the next sample's preamble ?
Assuming a source/transport that has a pretty good clock to begin with, and a DAC that can work just off LE (latch enable).
Why can't the sample data bits be extracted from the sub-frame, sent to the dac, followed by a 'latch enable' triggered by the detection of the next sample's preamble ?
Assuming a source/transport that has a pretty good clock to begin with, and a DAC that can work just off LE (latch enable).
Virtually all DACs use an interface called I2S, which is a serial interface consisting of data, bit clock, and word clock. For more information see here:
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
Hi Percy,
You do have to clock the individial data bits into the DAC.
Typically there is a shift register of some sort acting as a serial to parallel converter inside the DAC.
You need a clock I'm afraid.
Because nearly all DACs have a serial data input, most decoders have a serial output (it saves pins on the chip, and thus improves margins), so if you have an R2R DAC that has a parallel input, you'll still need to convert the serial data to parallel, so the shift register moves from inside the DAC to outside.
?
Cheers,
Phil
You do have to clock the individial data bits into the DAC.
Typically there is a shift register of some sort acting as a serial to parallel converter inside the DAC.
You need a clock I'm afraid.
Because nearly all DACs have a serial data input, most decoders have a serial output (it saves pins on the chip, and thus improves margins), so if you have an R2R DAC that has a parallel input, you'll still need to convert the serial data to parallel, so the shift register moves from inside the DAC to outside.
?
Cheers,
Phil
the clock that you are referring to is different from the "data rate" clock and has no relevance to the rate of flow. they both can be independent of each other.
you would need a pic/mcu of sorts to implement this idea and ofcourse the pic will need a clock to operate but that is not the same clock as the audio signal clock.
makes sense ?
for example, if that clock was way faster than the data rate then would it matter ?
you would need a pic/mcu of sorts to implement this idea and ofcourse the pic will need a clock to operate but that is not the same clock as the audio signal clock.
makes sense ?
for example, if that clock was way faster than the data rate then would it matter ?
Hi Percy,
I'm thoroughly confused.
The clock I'm referring to IS the clock used to clock in the data.
Typically, the minimum required signals into a DAC are:
*L/R clock, or LE based signal (a sample clock, if you like) running at either 1x or 2x the sample rate (2x if stereo).
So lets assume 88.2kHz.
*serial data input at a rate of word length x sample rate x number of channels (lets assume 2).
So typically, 16x44100x2 = ~1.41MHz
*A data clock at the same frequency as the data.
So, again, ~1.4MHz.
If oversampling, basically the frequency of all these parameters is multiplied by the oversampling rate.
(I know that it is common to have 32bit words for I2S for instance, I'm just simplifying things a bit).
So, the clock is the same rate as the data rate. If it was faster, it wouldn't work (0101 would be clocked in as 0011 0011 if the clock was 2x the data rate).
What clock do you mean?
What do I need a PIC for?
Cheers,
Phil
I'm thoroughly confused.
The clock I'm referring to IS the clock used to clock in the data.
Typically, the minimum required signals into a DAC are:
*L/R clock, or LE based signal (a sample clock, if you like) running at either 1x or 2x the sample rate (2x if stereo).
So lets assume 88.2kHz.
*serial data input at a rate of word length x sample rate x number of channels (lets assume 2).
So typically, 16x44100x2 = ~1.41MHz
*A data clock at the same frequency as the data.
So, again, ~1.4MHz.
If oversampling, basically the frequency of all these parameters is multiplied by the oversampling rate.
(I know that it is common to have 32bit words for I2S for instance, I'm just simplifying things a bit).
So, the clock is the same rate as the data rate. If it was faster, it wouldn't work (0101 would be clocked in as 0011 0011 if the clock was 2x the data rate).
What clock do you mean?
What do I need a PIC for?
Cheers,
Phil
Percy, do you mean by "clock" the signal that triggers the conversion? In the R-2R example this would be the signal that switches the registers' output to the ladder network. But where do you get this signal from? Well, you mentined the "peamble" of the next sample. I don't think such thing exists. Let's say all samples are 0s, so that 16 zeroes are clocked in the register (BTW, where is this clock coming from?). Then nothing indicates the beginning of the next sample.
Well, you have to recover the incoming bit clock (typically done using a PLL) in order to be able to decode the bits from the SPDIF stream. No clock recovery, no data at your disposal because you simply don't know when the bits come in. I guess this answers your question completely.
All clocks, whether bit or word or sample clock, are at fixed ratios for a certain sample rate, so by having one clock you automatically have them all by applying the correct division/multiplication ratios. Since the incoming bit clock is the highest in frequency, you typically recover this clock (which you must anyhow), and then obtain the other clock signals by division. This is much easier than recovering the SPDIF bit clock, extracting a word clock and then multiply it (which requires either controlled propagation delays plus a fair bit of logic, or a second PLL) to obtain whatever clock your DAC needs. The last option is like driving from Amsterdam to Rotterdam via Paris.
Several DAC topologies need a bit clock for their operation. An R-2R converter isn't used for high resolutions because of its limited accuracy. Think about the accuracy to which the resistors have to be trimmed for 16+ bit operation and you have a formidable job on hand. So some form of pipelined architecture is typically used, which starts a conversion at a word clock but needs a bit clock for its internal operation. There are stringent timing requirements between word and bit clock (notably their starting edges) in a DAC, that's why they are typically derived from the same master clock...
All clocks, whether bit or word or sample clock, are at fixed ratios for a certain sample rate, so by having one clock you automatically have them all by applying the correct division/multiplication ratios. Since the incoming bit clock is the highest in frequency, you typically recover this clock (which you must anyhow), and then obtain the other clock signals by division. This is much easier than recovering the SPDIF bit clock, extracting a word clock and then multiply it (which requires either controlled propagation delays plus a fair bit of logic, or a second PLL) to obtain whatever clock your DAC needs. The last option is like driving from Amsterdam to Rotterdam via Paris.
Several DAC topologies need a bit clock for their operation. An R-2R converter isn't used for high resolutions because of its limited accuracy. Think about the accuracy to which the resistors have to be trimmed for 16+ bit operation and you have a formidable job on hand. So some form of pipelined architecture is typically used, which starts a conversion at a word clock but needs a bit clock for its internal operation. There are stringent timing requirements between word and bit clock (notably their starting edges) in a DAC, that's why they are typically derived from the same master clock...
Spdif preamble detection is not uncommon (CS8416). Its a unique string of bits that can never exist in the sample data. The sample is BMC and the preamble has BMC violation. And in BMC there is no such thing as all 0's (or all 1's).
yes ofcourse you need a clock, but only to count and extract the sample bits between preambles. That clock can run at any speed it wants as long as 'it' knows how many bits to count for how many ticks. Each such extracted bit will then be moved('shifted') to a register. When the next preamble arrives, all those bits would be moved to the DAC register and the DAC will be triggered to convert that sample.
oh..and you need a pic to do all of that, which I suppose all modern day dacs do, so its nothing new really in that area.
yes ofcourse you need a clock, but only to count and extract the sample bits between preambles. That clock can run at any speed it wants as long as 'it' knows how many bits to count for how many ticks. Each such extracted bit will then be moved('shifted') to a register. When the next preamble arrives, all those bits would be moved to the DAC register and the DAC will be triggered to convert that sample.
oh..and you need a pic to do all of that, which I suppose all modern day dacs do, so its nothing new really in that area.
hi Percy,
Okay, I'm starting to understand you.
You're talking about using a PIC to decode SPDIF into data for sending to the DAC.
I think we assumed you were referring to the signals going into the DAC.
Because the DAC requires data that is serial, it needs a clock to clock it into the DAC.
Are you suggesting that a PIC is used to decode SPDIF into parallel data to feed straight into a DAC, and thus require only a sample clock?
I assume it would work if you could find a parallel input DAC. They exist, but you're suddenly limited in choice.
Cheers,
Phil
Okay, I'm starting to understand you.
You're talking about using a PIC to decode SPDIF into data for sending to the DAC.
I think we assumed you were referring to the signals going into the DAC.
Because the DAC requires data that is serial, it needs a clock to clock it into the DAC.
Are you suggesting that a PIC is used to decode SPDIF into parallel data to feed straight into a DAC, and thus require only a sample clock?
I assume it would work if you could find a parallel input DAC. They exist, but you're suddenly limited in choice.
Cheers,
Phil
Sir, blimey! I'm normally called much worse 
Well, if its feasible, if a suitable DAC exists, then it would work.
Whether it would be any better is debatable I guess.
It could be argued that with a lower clocking frequency (the clock would be the sample clock) then you do reduce the risk of jitter, but a normal DAC's output is likely to be triggered by the same sample clock.
And you do need to implement a PIC, which could add noise and interference in the power rails - but perhaps no more than an SPDIF receiver or a digital filter would.
But, you are using lower frequency signals at the DAC end, which seems more sensible...
Well, if its feasible, if a suitable DAC exists, then it would work.
Whether it would be any better is debatable I guess.
It could be argued that with a lower clocking frequency (the clock would be the sample clock) then you do reduce the risk of jitter, but a normal DAC's output is likely to be triggered by the same sample clock.
And you do need to implement a PIC, which could add noise and interference in the power rails - but perhaps no more than an SPDIF receiver or a digital filter would.
But, you are using lower frequency signals at the DAC end, which seems more sensible...
I noticed that TI makes a lot of parallel (infact r2r) dacs, some with less than stellar performance, but a couple of them are really worth noting.
Look at DAC8820/2. ±1LSB INL, 16-bit Monotonic. Although I didn't quite understand why the Bipolar Zero error was so high (±5 lsb??). Unless it can be 'calibrated' to ±1LSB somehow.
I didn't find SNR or DR specs either.
Interesting that these DACs are not under their "audio' section, and also for obsolete dacs like pcm54/55/56 they recommend one of these new ones(DAC7742, DAC8580) instead.
Look at DAC8820/2. ±1LSB INL, 16-bit Monotonic. Although I didn't quite understand why the Bipolar Zero error was so high (±5 lsb??). Unless it can be 'calibrated' to ±1LSB somehow.
I didn't find SNR or DR specs either.
Interesting that these DACs are not under their "audio' section, and also for obsolete dacs like pcm54/55/56 they recommend one of these new ones(DAC7742, DAC8580) instead.
Frankly, I didn't know about the existence of these ICs. And even the price at Digi Key doesn't seem too outrageous too! I always had the impression that 10 to 12 bits was about as many bits as an R2R DACwould get. But the external Vref input makes it clear why it is worthwile to expand this topology to 16 bits, many DAC's don't provide this flexibility! Interesting device...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.