If you can somehow slave the DAC to the transport there's little or no advantage to upsampling with an SRC. That's the whole point of the ASRC, to reclock the incoming data according to the new system clock. If you can do the slave thing (and for heaven's sake don't try to send the TTL clock over a normal cable; it must be a differential transmission line or the jitter will be horrible) it's the best to upgrade to a high-end clock that clocks both and forget about the whole SRC thing. If you're slaved with the same clock, then feeding the DAC with 192kHz audio simply because the SRC can do it is pretty much like wetting yourself.. it gives that warm feeling but somehow something doesn't feel right 
Oversampling is a different matter altogether though, but with almost all delta-sigma ones having one anyway it's a moot point. I do miss the DF1704 though, it's been a lovely OS filter.
I prefer to use the SRC4392 (similar but more flexible than SRC4192/3) in slave-slave with an external clock divider as master to make both DAC and SRC slaves. This is easy since I'm using an FPGA to clock in the data from the SRC instead of a DAC, and with that it's simple to use counters and/or PLL's to create the BCK and LRCK. There's little difference to using the synchronous MCK for the SRC's RCKI compared to a separate free-standing oscillator feeding it RCKI. Something for a rainy day I suppose, test both configurations and measure up the performance with an Audio Precision.
However for people just using a normal DAC as target, slave in master out is the best configuration, although I suspect a proper hardware counter to generate the LRCK and BCK from MCK may be a better solution.
Oversampling is a different matter altogether though, but with almost all delta-sigma ones having one anyway it's a moot point. I do miss the DF1704 though, it's been a lovely OS filter.I prefer to use the SRC4392 (similar but more flexible than SRC4192/3) in slave-slave with an external clock divider as master to make both DAC and SRC slaves. This is easy since I'm using an FPGA to clock in the data from the SRC instead of a DAC, and with that it's simple to use counters and/or PLL's to create the BCK and LRCK. There's little difference to using the synchronous MCK for the SRC's RCKI compared to a separate free-standing oscillator feeding it RCKI. Something for a rainy day I suppose, test both configurations and measure up the performance with an Audio Precision.
However for people just using a normal DAC as target, slave in master out is the best configuration, although I suspect a proper hardware counter to generate the LRCK and BCK from MCK may be a better solution.
The easiest way to build this is actually to slave the DACs to the transport, as the CD-Pro2 transport has a designated master clock output. That's the way I was going to do it until I came to think about upsampling. It might be better to run separate wires from the clock to transport and DACs though, so it doesn't have to travel through the transport on its way to the DAC. Or am I wrong again? And don't worry, I'll use the coax cable that's supplied with the clock.
And what about isolation transformers? I'll be running a dual mono setup with separate DACs and power supplies for each channel.
Running LRCK and BCK on the DAC off the master through a counter shouldn't be a problem, but I don't really see the point. It would seem hard to sync that to the transport output too.
The 1794 has an 8x oversampling input filter (is oversampling and upsampling the same thing?), which also converts 16 bit data to the 24 bit resolution it works with internally. Does all that mean that I don't need a separate chip for upsampling? I know the question might sound stupid after your explanation, but I'm easily confused...
The SRC4392 looks nice, but taking on software control is a bit too much for this project
And what about isolation transformers? I'll be running a dual mono setup with separate DACs and power supplies for each channel.
Running LRCK and BCK on the DAC off the master through a counter shouldn't be a problem, but I don't really see the point. It would seem hard to sync that to the transport output too.
The 1794 has an 8x oversampling input filter (is oversampling and upsampling the same thing?), which also converts 16 bit data to the 24 bit resolution it works with internally. Does all that mean that I don't need a separate chip for upsampling? I know the question might sound stupid after your explanation, but I'm easily confused...
The SRC4392 looks nice, but taking on software control is a bit too much for this project
You don't need upsampling. It's a design decision, really. Theoretically, at least, upsampling before the DAC can ease the post-DAC filtering by moving out-of-band images away from the audible spectrum, thereby attenuating the problems associated with brickwall filters. However, with the PCM1794 you can use the "slow" rolloff digital filter, which should have some of the same effects. It sure would make your DAC much less complex to avoid the ASRC, especially if you synch the clock from your transport. Just my two cents.
True about the higher-spaced aliasing images. IMO rather just use a DAC with a better filter (compare 1794 to 1798) and it'll make a bigger difference. Unless of course the 1794's isn't good enough for some anyway, you can always score a DF1706 from somewhere to make it even better.
I'm not sure what you want to do but it sounds like you want to clock the transport with a SuperClock or something, and then take that clock out along with the S/PDIF to the outboard DAC.
That coax is only going to help you to a point. I've always been amused by those clocks; they come neatly with a 50ohm cable and SMA connector, with a naked endpoint that one's just supposed to solder to the clock pins. Screw the whole impedance-matching thing that was done so carefully at the source side. If you can't fit in the SMA connector, at least terminate it properly at the chip. If you want to clock two things with the same clock in parallel without a buffer it just gets worse with multiple reflections.
I'd rather terminate the clock it at the transport, and run a nice buffered differential line to the DAC, and convert it back to TTL there. Options are terminate and fanout buffer, one driving the transport and the other out to the DAC. Otherwise, since you don't want differential at the transport though, terminate at the transport (no buffer needed), and buffer from there with a differential buffer to go to the DAC. True you'll get a few ns delay between the transport and DAC clock, but it's the two clocks being synchronous that matters, not a slight phase difference.
The only way to faitfully transmit the clocks will be with a proper differential transmitting standard like ECL or LVDS, over a proper 50/100ohms transmission-line. I know some people use TTL over coax but it doesn't mean it's right. ECL works well though, but differential is the way to go for anything that has to leave the chassis. Linn has cheated slightly and used an extra cable besides the S/PDIF to just transmit the clock error signal that's very low in frequency.
In all the best way would be to bypass S/PDIF altogether and run the data and three clock lines all from the transport to the DAC and make sure everything's well impedance-matched. I've been doing some experiments using it with great success over long (even 30m works easily) distances between transport and DAC.
Transformers won't work well since the digital output has a DC component i.e. it rides between 0 and 3.3/5V, not symmetrically around zero. You'll need extra buffers to make transformers work.
I'm not sure what you want to do but it sounds like you want to clock the transport with a SuperClock or something, and then take that clock out along with the S/PDIF to the outboard DAC.
That coax is only going to help you to a point. I've always been amused by those clocks; they come neatly with a 50ohm cable and SMA connector, with a naked endpoint that one's just supposed to solder to the clock pins. Screw the whole impedance-matching thing that was done so carefully at the source side. If you can't fit in the SMA connector, at least terminate it properly at the chip. If you want to clock two things with the same clock in parallel without a buffer it just gets worse with multiple reflections.
I'd rather terminate the clock it at the transport, and run a nice buffered differential line to the DAC, and convert it back to TTL there. Options are terminate and fanout buffer, one driving the transport and the other out to the DAC. Otherwise, since you don't want differential at the transport though, terminate at the transport (no buffer needed), and buffer from there with a differential buffer to go to the DAC. True you'll get a few ns delay between the transport and DAC clock, but it's the two clocks being synchronous that matters, not a slight phase difference.
The only way to faitfully transmit the clocks will be with a proper differential transmitting standard like ECL or LVDS, over a proper 50/100ohms transmission-line. I know some people use TTL over coax but it doesn't mean it's right. ECL works well though, but differential is the way to go for anything that has to leave the chassis. Linn has cheated slightly and used an extra cable besides the S/PDIF to just transmit the clock error signal that's very low in frequency.
In all the best way would be to bypass S/PDIF altogether and run the data and three clock lines all from the transport to the DAC and make sure everything's well impedance-matched. I've been doing some experiments using it with great success over long (even 30m works easily) distances between transport and DAC.
Transformers won't work well since the digital output has a DC component i.e. it rides between 0 and 3.3/5V, not symmetrically around zero. You'll need extra buffers to make transformers work.
I'm planning using one 1794 in mono mode on each channel. I checked the 1798 too, but it's grossly outperformed by the 1794 in every aspect, and the digital filter in particular. It's more than three times more expensive than the 1798, though, but whether it's 6 or 20 bucks for two DACs isn't going to make a whole lot of difference.
Yes, I'll be using a NewClassD clock, made by the founder of LC Audio in Denmark. From what I've read, it's just about the best there is. What I want it to do is clock a transport and two DACs, but I don't have a clue what's the best way to do it. What seems most logical, given the available connections, is to run the clock directly to the transport, and run it from there to each of the DACs, along with LRCK, BCK and data.
I've obviously not made it very clear, but this is going to be an integrated CD player, with two DACs running in dual mono. Unmodified I2S will run directly from the transport to each of the DACs. The distance from clock to transport can be as short as 5-10 cm, and if necessary, so can the distance between transport and DAC.
You have to forgive me if I sound stupid, but I don't have the slightest clue as to how high frequency signals work and behave, nor what buffers are. A tea spoon feeding of routing and wiring would be greatly appreciated
Yes, I'll be using a NewClassD clock, made by the founder of LC Audio in Denmark. From what I've read, it's just about the best there is. What I want it to do is clock a transport and two DACs, but I don't have a clue what's the best way to do it. What seems most logical, given the available connections, is to run the clock directly to the transport, and run it from there to each of the DACs, along with LRCK, BCK and data.
I've obviously not made it very clear, but this is going to be an integrated CD player, with two DACs running in dual mono. Unmodified I2S will run directly from the transport to each of the DACs. The distance from clock to transport can be as short as 5-10 cm, and if necessary, so can the distance between transport and DAC.
You have to forgive me if I sound stupid, but I don't have the slightest clue as to how high frequency signals work and behave, nor what buffers are. A tea spoon feeding of routing and wiring would be greatly appreciated
OK, so with the shorter distances you're a bit more forgiven
HOWEVER, when it comes to transmission lines, distance is of fairly little concern.
The main problem comes at the master clock. If your clock is like the SuperClock I've bought for investigation (what an utter waste of money when it came to jitter measurements but that's another story), it should have a well-defined characteristic output impedance. You would like to keep that, or a lot of its potential will be degraded. Find out if that clock is indeed a 50ohm transmission line. (i.e. 50ohm cable and 50ohm output impedance). If not, and it's just a plain unmatched TTL signal, skip to the next paragraph and treat MCK the same as the other three. If it is a 50ohm line (it's very unlikely to be 75), keep the same cable supplied, and if you can get an SMA connector it'd be even better. Otherwise use a BNC one, but they're difficult to fit on those thin coax cables. As close as possible to the clock you should build a small PCB with the input connector for the clock, and a buffer compatible with the logic level (CMOS or TTL), with a 50ohm resistor between ground and the input pin. That buffer should preferably be a fanout one, i.e. one input and multiple outputs. From there, drive the transport and the DAC's with each of the outputs directly. That way, the clock only sees one load, and each of the targets are driven by a separate buffer.
The MCK is now in plain TTL format, the same as the rest. You should do the same buffer thing with the LRCK, BCK and data lines, except without the termination part. Keep the buffer PCB as close to the source as possible, and keep the signal cables separate.
You can transmit the four buffered signals fairly well in TTL with ribbon cable, but make sure every 2nd conductor is grounded, i.e. one row of the IDC connector. That way you'll have minimal capacitive crosscoupling. You should also add a small resistor, perhaps even in series with a ferrite bead, at the DAC input side as well to damp the energy transmitted. A resistor at the source side may also help a bit, but it depends on a few parameters.
As to the choice of fanout buffer, look at TI's CDCV304 for an idea, but first make sure of the logic level of the transport and MCK. I bet it's the old 5V instead of 3.3V, so look for something similar with 5V logic levels, or a 3.3V one with 5V tolerant inputs. The PCM1794 is nice enough to have 5V tolerant inputs with 3.3V power. Don't use a logic translator in series with a fanout buffer, they just add unnecessary skew and jitter. Look for the 5V-tolerant inputs or a plain 5V one.
The CDCV has 4 outputs for one input. Use four of these chips, one per signal, and leave the unused outputs. Your "distribution PCB" should therefore contain the four buffers and a voltage regulator fed from wherever you can get something cleanish and high enough. From there the input terminals, and at the output preferably something like an IDC header with ribbon cable, it looks so much better than soldered.
If everything still seems hazy, msg me and I'll explain further in email.
HOWEVER, when it comes to transmission lines, distance is of fairly little concern.
The main problem comes at the master clock. If your clock is like the SuperClock I've bought for investigation (what an utter waste of money when it came to jitter measurements but that's another story), it should have a well-defined characteristic output impedance. You would like to keep that, or a lot of its potential will be degraded. Find out if that clock is indeed a 50ohm transmission line. (i.e. 50ohm cable and 50ohm output impedance). If not, and it's just a plain unmatched TTL signal, skip to the next paragraph and treat MCK the same as the other three. If it is a 50ohm line (it's very unlikely to be 75), keep the same cable supplied, and if you can get an SMA connector it'd be even better. Otherwise use a BNC one, but they're difficult to fit on those thin coax cables. As close as possible to the clock you should build a small PCB with the input connector for the clock, and a buffer compatible with the logic level (CMOS or TTL), with a 50ohm resistor between ground and the input pin. That buffer should preferably be a fanout one, i.e. one input and multiple outputs. From there, drive the transport and the DAC's with each of the outputs directly. That way, the clock only sees one load, and each of the targets are driven by a separate buffer.
The MCK is now in plain TTL format, the same as the rest. You should do the same buffer thing with the LRCK, BCK and data lines, except without the termination part. Keep the buffer PCB as close to the source as possible, and keep the signal cables separate.
You can transmit the four buffered signals fairly well in TTL with ribbon cable, but make sure every 2nd conductor is grounded, i.e. one row of the IDC connector. That way you'll have minimal capacitive crosscoupling. You should also add a small resistor, perhaps even in series with a ferrite bead, at the DAC input side as well to damp the energy transmitted. A resistor at the source side may also help a bit, but it depends on a few parameters.
As to the choice of fanout buffer, look at TI's CDCV304 for an idea, but first make sure of the logic level of the transport and MCK. I bet it's the old 5V instead of 3.3V, so look for something similar with 5V logic levels, or a 3.3V one with 5V tolerant inputs. The PCM1794 is nice enough to have 5V tolerant inputs with 3.3V power. Don't use a logic translator in series with a fanout buffer, they just add unnecessary skew and jitter. Look for the 5V-tolerant inputs or a plain 5V one.
The CDCV has 4 outputs for one input. Use four of these chips, one per signal, and leave the unused outputs. Your "distribution PCB" should therefore contain the four buffers and a voltage regulator fed from wherever you can get something cleanish and high enough. From there the input terminals, and at the output preferably something like an IDC header with ribbon cable, it looks so much better than soldered.
If everything still seems hazy, msg me and I'll explain further in email.
Thanks a lot, that answered all the questions I had! It gave me a few new ones I'd like to ask you about, but I can't seem to find your e-mail anywhere. There should have been a PM function on this board...
I'll be using the NewClassD clock, if you want to check it out.
I'll be using the NewClassD clock, if you want to check it out.
hi novec,
just to say that that's great for me all you've treated on this post.
I'm actually looking for an internal DAC to join to a CDPRO2.
I2S interface is higly likely to be used.
I'd like to know what kind of signal I'll have if I connect directly I2S outpout to PCM1794 ? 16 bit 44.1kHz ?
then if I add between those a SRC4192 I could have up to 192kHz signal but not upsambling ? right ?
I'm just trying to design my own DAC, with little knowledge... so please excuse me if I'm asking "that newbie" questions... and if you could help me, that would be really great !
just to say that that's great for me all you've treated on this post.
I'm actually looking for an internal DAC to join to a CDPRO2.
I2S interface is higly likely to be used.
I'd like to know what kind of signal I'll have if I connect directly I2S outpout to PCM1794 ? 16 bit 44.1kHz ?
then if I add between those a SRC4192 I could have up to 192kHz signal but not upsambling ? right ?
I'm just trying to design my own DAC, with little knowledge... so please excuse me if I'm asking "that newbie" questions... and if you could help me, that would be really great !
Thanks, cowbolt. You're right, I2S is the way to go. The simplest route, whis is what I'll do, is to just run I2S straight to the DAC. This will be a standard 16 bit 44.1 kHz signal, which the DAC will do fine with. You can also connect the 16 MHz clock output from the CD-PRO2 directly to the DAC, so you're sure they're in sync.
I haven't looked any further into upsamplers, but you should be able to bring it all the way up to 24 bit 192 kHz with the right upsampler, which the DAC is also happy to receive. Regardless of input signal, the DAC will do an internal 8x oversampling of the signal, but that's just internally in the DAC and nothing you need to worry about.
I haven't looked any further into upsamplers, but you should be able to bring it all the way up to 24 bit 192 kHz with the right upsampler, which the DAC is also happy to receive. Regardless of input signal, the DAC will do an internal 8x oversampling of the signal, but that's just internally in the DAC and nothing you need to worry about.
hi novec, thanks for your quick reply
I got some more information on the web about DAC's structures.
I now understand that if I connect I2S outpout from the CDPRO2M to the PCM 1794, I can have a good outpout signal.
I have also read the data sheet of PCM1794 and can't understand how the OS rate works? can we choose the rate ? is it linked to the clock we choose ?
other point perhaps you can answer, what do I gain if I upsample I2S signal via SRC4192 ? is it possible to upsample I2S or is it just for PCM signal ??
I got some more information on the web about DAC's structures.
I now understand that if I connect I2S outpout from the CDPRO2M to the PCM 1794, I can have a good outpout signal.
I have also read the data sheet of PCM1794 and can't understand how the OS rate works? can we choose the rate ? is it linked to the clock we choose ?
other point perhaps you can answer, what do I gain if I upsample I2S signal via SRC4192 ? is it possible to upsample I2S or is it just for PCM signal ??
It seems you've misunderstood the exact same thing I did. The 1794 has an internally oversampling input filter, which means it takes whatever input signal it gets and oversamples it 8 times to have a more accurate signal to work with internally. It does not upsample the input signal, i.e. from 44.1 kHz CD signal to 192 kHz, that would require an external chip. However, adding an ASRC to do the upsampling would also require an extra clock, and possibly some controller circuits.
All in all, upsampling to 192/24 means a whole lot of complicated circuitry, which in turn means a bigger challenge in power supply and PCB design and more places things can go wrong and/or pick up noise. And as several posters in this thread have pointed out, the advantage of upsampling in this application isn't all that clear. My advice would be to go the simple route and connect the 1794 directly to the CD-PRO2 via I2S.
I'm leaving for St. Anton in a few hours, and won't be back 'till over easter, but I'm sure other posters will answer any more questions you might have.
All in all, upsampling to 192/24 means a whole lot of complicated circuitry, which in turn means a bigger challenge in power supply and PCB design and more places things can go wrong and/or pick up noise. And as several posters in this thread have pointed out, the advantage of upsampling in this application isn't all that clear. My advice would be to go the simple route and connect the 1794 directly to the CD-PRO2 via I2S.
I'm leaving for St. Anton in a few hours, and won't be back 'till over easter, but I'm sure other posters will answer any more questions you might have.
thank you novec,
you're right, I realised it last night before sleeping I read once more PCM 1794's data sheet and understood that the chip was oversampling the input signal.
well of course I'll probably start with I2s output directly connected to 2chips, one for each channel and Hardware configured in"mono".
but as I'm not really hurried, I'm trying to get as much informations as I can.
So I'm now looking at the SRC4192, as you may have done before me, and trying to guess if it would upsample the signal from 16bits to 24bits.
I perhaps misundertand DAC's rules
but I see that the data sheet of PCM1794 is measured with 24bit signal input.
I suppose that if I want to reach the performance announced, I have to upsample the signal, right ?
thank you all for your support.
you're right, I realised it last night before sleeping
I read once more PCM 1794's data sheet and understood that the chip was oversampling the input signal.well of course I'll probably start with I2s output directly connected to 2chips, one for each channel and Hardware configured in"mono".
but as I'm not really hurried, I'm trying to get as much informations as I can.
So I'm now looking at the SRC4192, as you may have done before me
, and trying to guess if it would upsample the signal from 16bits to 24bits. I perhaps misundertand DAC's rules
but I see that the data sheet of PCM1794 is measured with 24bit signal input.I suppose that if I want to reach the performance announced, I have to upsample the signal, right ?
thank you all for your support.
To get the spec'ed performance out of your DAC you'll have to feed it a 24 bit signal, that's right, but I'm not sure that a 24 signal upsampled from 16 bit will sound any better than an unaltered 16 bit signal in a DIY situation.
But now we're wandering into the "is upsampling better"-discussion again. I tend to think it is, if properly implemented. From what little I've gathered about circuit design, you'd better be skilled and have access to proper boards and supplies to properly implement those higher grade electronics. Not for the regular DIY, in other words.
But now we're wandering into the "is upsampling better"-discussion again. I tend to think it is, if properly implemented. From what little I've gathered about circuit design, you'd better be skilled and have access to proper boards and supplies to properly implement those higher grade electronics. Not for the regular DIY, in other words.
thanks Novec,
I read a lot about how to upsample the CDPRO's I²S signal. I foud a solution that could be rather easy
it seems that using DIR1703 (replaced by DIR9001 from TI) can allow I2S 16 bit input and I2S 24 bit outpout... to be confirmed of course... those datasheets seem so hard to understand for a "common DIYer" as you say.
I'll certainly built a DAC based on PCM1794.
For the moment, I try to find a good I/V section, because without it, the DAC is worthless
then, I'll perhaps try to "improve" with upsampling and oversampling. there, I'll tell you about what I've done
I read a lot about how to upsample the CDPRO's I²S signal. I foud a solution that could be rather easy
it seems that using DIR1703 (replaced by DIR9001 from TI) can allow I2S 16 bit input and I2S 24 bit outpout... to be confirmed of course... those datasheets seem so hard to understand for a "common DIYer" as you say.
I'll certainly built a DAC based on PCM1794.
For the moment, I try to find a good I/V section, because without it, the DAC is worthless
then, I'll perhaps try to "improve" with upsampling and oversampling. there, I'll tell you about what I've done
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.