Hi Martin,
10pF. What am I saying. Sorry, getting muddled, I did mean 10nF (I know its bigger than the 2.2 suggested in the datasheet).
Anyway, since then, I have lowered the resistance to 820 ohms, and the sound is attenuated, but the same problem exists.
So, I'm eliminating things, and despite the datasheet suggesting that the I2S input is resynchronised internally, I do wonder if it is the problem (reinforced by rfbrw). Its a thought that keeps haunting me.
Tubee, that 304 sounds crazy! However, I think I can rule out power rail noise now as I connected the 7220 up to the power and I2S input, but didn't connect the output up, instead connected the TDA1541A straight to the NOS I2S (that really is the wrong term for it) and it sounded fine. So, the 7220 is not upsetting the power to the 1541 or opamp stages.
It is possible that the decoupling is not good enough for the saa7220, and it is dropping out, but I find it hard to believe. It has a reasonably close 2000uF decoupling cap. It is very easy to eliminate that one with just a 0.1uF or similar under the chip between gnd and vdd.
So, I shall double check the decoupling, because its quick to do (and should be done for completeness) and then work on a reclocking module.
I did think about using the output stage of the CD610 I pinched this SAA7220 from to check if the noise still occurs (just attach the I2S into the DAC inputs on board), but at the moment I suspect the issue is downstream of the DAC so I doubt it will help much.
Thanks for all the help.
Cheers,
Phil
10pF. What am I saying. Sorry, getting muddled, I did mean 10nF (I know its bigger than the 2.2 suggested in the datasheet).
Anyway, since then, I have lowered the resistance to 820 ohms, and the sound is attenuated, but the same problem exists.
So, I'm eliminating things, and despite the datasheet suggesting that the I2S input is resynchronised internally, I do wonder if it is the problem (reinforced by rfbrw). Its a thought that keeps haunting me.
Tubee, that 304 sounds crazy! However, I think I can rule out power rail noise now as I connected the 7220 up to the power and I2S input, but didn't connect the output up, instead connected the TDA1541A straight to the NOS I2S (that really is the wrong term for it) and it sounded fine. So, the 7220 is not upsetting the power to the 1541 or opamp stages.
It is possible that the decoupling is not good enough for the saa7220, and it is dropping out, but I find it hard to believe. It has a reasonably close 2000uF decoupling cap. It is very easy to eliminate that one with just a 0.1uF or similar under the chip between gnd and vdd.
So, I shall double check the decoupling, because its quick to do (and should be done for completeness) and then work on a reclocking module.
I did think about using the output stage of the CD610 I pinched this SAA7220 from to check if the noise still occurs (just attach the I2S into the DAC inputs on board), but at the moment I suspect the issue is downstream of the DAC so I doubt it will help much.
Thanks for all the help.
Cheers,
Phil
Tubee,
My DAC has a 7220 in it at the moment, with a 3rd order filter, not very NOS like, with a peculiar buzzing noise. LOL!
I will get there.
Another thing for completeness (scraping the barrel before I go off to build a reclocker) is to terminate the digital output with 75 ohms. Haven't done it yet, but its cheap to do.
I can see why there are so many DIY NOS DACs in comparison to DIY oversampling DACs, but I still am keen to get this going.
My DAC has a 7220 in it at the moment, with a 3rd order filter, not very NOS like, with a peculiar buzzing noise. LOL!
I will get there.
Another thing for completeness (scraping the barrel before I go off to build a reclocker) is to terminate the digital output with 75 ohms. Haven't done it yet, but its cheap to do.
I can see why there are so many DIY NOS DACs in comparison to DIY oversampling DACs, but I still am keen to get this going.
Hi rfbrw,
Maybe, to be more precise, there seems to be far less people trying 7220->1541.
NOS DACs have their benefits. Whether people like them or not, they are enabling people to build DACs that they did not suspect they'd be able to.
I wouldn't be messing around with an SAA7220 (which I am actually enjoying - despite my grumblings) if it wasn't for my first NOS DAC.
But, it did clearly say it resynchronises inputs to its internal clock, in black and white. I should know better than to trust a datasheet.
Anyway, I shall be doing the exact same thing before the I2S reaches the SAA7220, just to be sure.
At least I'm following your footer's advice, work harder, not smarter
Cheers,
Phil
I agree about the NOS DACs, but I struggle to find so many OS DACs out there. They exist, but there are so many more NOS DACs out there and (re)documented (which surprised me when I started this project looking for inspiration).
Maybe, to be more precise, there seems to be far less people trying 7220->1541.
NOS DACs have their benefits. Whether people like them or not, they are enabling people to build DACs that they did not suspect they'd be able to.
I wouldn't be messing around with an SAA7220 (which I am actually enjoying - despite my grumblings) if it wasn't for my first NOS DAC.
Fair enough, I did cut a corner originally to quickly try this oversampler out, and trusted a datasheet - two fundamental errors there.
But, it did clearly say it resynchronises inputs to its internal clock, in black and white. I should know better than to trust a datasheet.
Anyway, I shall be doing the exact same thing before the I2S reaches the SAA7220, just to be sure.
At least I'm following your footer's advice, work harder, not smarter
Cheers,
Phil
philpoole said:
Correction. So many more instances of the same two or so dacs.
As for documentation, what can there be to document ?
Odds are if you are interested in oversampling, you've moved on to better devices.
Actually, it gives a false impression of what is required and leads the unwary up the garden path. You should trawl through some of the requests for help involving nos dacs. The mind boggles.
I'm glad to be of service to the entertainment industry! Problem is, I'm struggling to find the blinking obvious.
rfbrw enjoys making others think for themselves, which is important, but I think he enjoys it too much.
(and I didn't exactly mean abuse either, couldn't think of a better word)
Tubee,
without using the 7220, the bclk and data frequencies into the tda1541a are standard NOS frequencies 2MHz ish. With the TDA1541a, there is the 11Mhz oscillator, and the I2S bclk is doubled to about 5MHz (16bits per word, the input is 32bits per word - last time I looked at the datasheet).
Cheers,
Phil
Having chosen to ignore the datasheet, you shouldn't be too surprised if you come unstuck. Page 13 clearly shows the filter, the decoder and the dac in the same clock domain, i.e all driven by the same clock. The only difference when using the '1541A instead of the '1541 is that XSYS is not needed.
rfbrw, I know you've been hinting at this for so long, and I (until now ) have been of the opinion that resyncing would sort this.
To some extent, I think this is true, excluding the fact that the two clock domains are drifting - which I can only assume is causing samples to be dropped and thus the noise.
I deliberately haven't wanted to make the transport the slave, I like the clock module in it, but it appears to be the solution.
I always thought the main reason to enslave the transport was to reduce jitter, not actually to make the thing work.
Anyway, I have a very untidy setup, with a twisted pair feeding the decoder of my player fed by the saa7220 XSYS, the clock module in my transport now redundant, and 4x oversampling working. Hurray!
Thanks all for the help, for the sanity checking, hints and answers.
Now the 'week long experiment' LOL is over, I am going to have to go away and redesign my link between the DAC and transport (I won't be able to turn on the player before the DAC, d'oh!).
(at least what I did have was good for NOS)
Despite my fundamental design error, I haven't had any major issues with regard to power rail pollution, and I suspect I can setup a sensible clock module that can feed the different parts of the DAC so they don't have to traverse the 7220. However, I have the advantage of my own handbuilt DAC, and I'm not working within the constraints of a CD player.
With regard to the all important 'NOS vs 4xOS' argument. I've only heard a few tracks with the SAA7220, and it obviously has a rubbish clock compared to my NOS setup, but its quite respectable. Sounds good, more treble (as expected I guess), plenty of detail.
I am looking forward to rebuilding this into something more sensible to give it a fair test.
And, for the record, you can just 'shove' an SAA7220 in the I2S path and it should work (as long as it enslaves the transport!!). I've tested it and double checked everything. You don't need to worry about SCAB, SDAB, EFAB (although it would be an added bonus), MUTE* or ATSB* as they're all internally pulled to default settings.
Thanks again everyone for the help.
Cheers,
Phil
) have been of the opinion that resyncing would sort this.To some extent, I think this is true, excluding the fact that the two clock domains are drifting - which I can only assume is causing samples to be dropped and thus the noise.
I deliberately haven't wanted to make the transport the slave, I like the clock module in it, but it appears to be the solution.
I always thought the main reason to enslave the transport was to reduce jitter, not actually to make the thing work.
Anyway, I have a very untidy setup, with a twisted pair feeding the decoder of my player fed by the saa7220 XSYS, the clock module in my transport now redundant, and 4x oversampling working. Hurray!
Thanks all for the help, for the sanity checking, hints and answers.
Now the 'week long experiment' LOL is over, I am going to have to go away and redesign my link between the DAC and transport (I won't be able to turn on the player before the DAC, d'oh!).
(at least what I did have was good for NOS)
Despite my fundamental design error, I haven't had any major issues with regard to power rail pollution, and I suspect I can setup a sensible clock module that can feed the different parts of the DAC so they don't have to traverse the 7220. However, I have the advantage of my own handbuilt DAC, and I'm not working within the constraints of a CD player.
With regard to the all important 'NOS vs 4xOS' argument. I've only heard a few tracks with the SAA7220, and it obviously has a rubbish clock compared to my NOS setup, but its quite respectable. Sounds good, more treble (as expected I guess), plenty of detail.
I am looking forward to rebuilding this into something more sensible to give it a fair test.
And, for the record, you can just 'shove' an SAA7220 in the I2S path and it should work (as long as it enslaves the transport!!). I've tested it and double checked everything. You don't need to worry about SCAB, SDAB, EFAB (although it would be an added bonus), MUTE* or ATSB* as they're all internally pulled to default settings.
Thanks again everyone for the help.
Cheers,
Phil
