TDA1541 / SAA7220 DAC project

[knudsenuk]

Hi folks,
I made a TDA1541 DAC some time ago and was quite happy with it until I bought a Rotel 855 CD player which I also mucked about with and in then end preferred. The only obvious difference (aside from the digital source) was that the CD player had the SAA7220 digital filter before the DAC chip.
So I decided to make a module for the SAA7220 and it sort of works, but there is noise, like an untuned radio hiss until play is pressed and even then there is interference.

The setup consists of an RPI with a Kali reclocker hat, this goes to the SAA chip which then goes to the TDA. I feel the clock setup might be the issue as there is a clock for the Kali and the SAA chip (I have used the standard datasheet arrangement) has this resulted in two masters?. Can anyone suggest how this should be configured. My understanding is there is no provision to run a Pi in slave mode?

The other question is can the SAA7220 be run without the SAA7210 chip. Ideally I need an I2S input accepted from the Pi. I wondered also if the SAA7220 can be run without inputs to the  subcode pins.

Any help appreciated as I am stumped.....thanks Rich

[moffy]

Looking at the datasheets I think you are right, you would probably need to use a PLL clock synthesiser to synthesize the clock for the SA7220 from the BCLK coming from your Kali board.
The synthesized clock might need to be phase synchronized as well, if transitions would need to align.

[Gyro]

They did get it nicely right on the RCD855. If you're running the SAA7220 from its own crystal then, yes, you're going to run into all sorts of problems with I²S very audible data stream corruption. In Philips based players, the 7220 is generally used as the MCLK source for the player (although the 7210 also has the capability but I've never seen it used).

SCK (variously referred to as XSYS and SCK in various datasheets) needs to be 256 x I²S BCLK, so 11.2896MHz for 44.1kHz, 12.288MHZ for 48kHz - the highest you can run the SAA7220/TDA1541, 4 x oversampling. As moffy says, if you can't slave the Pi to MCLK then you will need to generate a synchronized MCLK from the Pi's BCLK output.

 Irrc, you shouldn't need to worry about the subcode inputs, they are there to support the optional S/PDIF output. You will need to tie the error flag, mute and atten inputs correctly though.

Note that the SAA7220 can be a noisy chip. Good local regulation and decoupling are needed. Supply noise can also make the on-chip crystal oscillator circuit more jittery too. The TDA1541 also has an SCK input which is used to (optionally?) reclock its I²S data input for reduced jitter. This was abandoned on the TDA1541A as unnecessary (at the same time, the DEM clock oscillator capacitor was moved from on-chip to external for reduced jitter).

Be careful where you source your SAA7220s from. The ones from China (if they are actually filters) may be re-marked SAA7220PCs. The optimal matchings are SAA7220PA for the TDA1541, SAA7220PB for the TDA1541A (which doesn't include the offset that is needed to make the TDA1541 perform optimally and also has better filter ROM coefficients). The SAA7220PC was designed for early digital receiver use at 32kHz and is not optimal for normal usage.

[knudsenuk]

Thanks both. I might see what happens if I send the clock signal to the kali board and disconnect the incumbent oscillator. Another idea is to take the I2S signal from my rotel from the saa7220 and feed my dac directly. I know there is no defined spec for wiring I2S but wondered if anyone else had views in how best to attempt it?

[Gyro]

I'm not sure what you mean by 'no defined spec for wiring I²S', Philips defined it very well... https://www.nxp.com/docs/en/user-manual/UM11732.pdf

It's a very basic interface, with just Clock (SCK), Data (SDA) and Word select, effectively L/R channel data select (WS). All signals are 5V/TTL compatible. Yes, if you have a 256 times clock available, you can feed it into the XIN pin of the SAA7220 (instead of the crystal).

Yes, you could also use the I²S output of of the SAA7220 on the RCD855. You should take appropriate precautions - ensure that you have a solid 0V connection between the RCD855 board and your DAC board, as close to the SAA7220 as possible. It would be a sensible precaution to put some series resistors in the signals, close to the SAA7220 - 120R for SCK and 390R for SDA and WS. These will provide a degree of short circuit protection and help with signal integrity. Observe ESD precautions.

[knudsenuk]

Sorry not quite what I meant. There is no defined approach to sending I2S via cable (box to box). I  have seen some audio equipment people using the HDMI connectors.

[Gyro]

Ah, I'm with you now. I was hoping that your DAC board would be small enough to fit into the RCD855's considerable free space, which would make things a great deal easier. No, I²S isn't a normal interface to use between transport and DAC, so people (I don't know if there are any manufacturers) do their own thing.

HDMI cable is overkill for even oversampled I²S and an awkward connector form factor. The SCK is only around 5.6MHz for 4x oversampled 44.1kHz. I've successfully used Cat 5 cable for S/PDIF one way and 11.2896MHz the other way to slave clock the transport. In this case i was able to use transformer isolation but that wouldn't be possible with I²S. Still Cat 5 (or Cat 6) with RJ45 connectors gives you four twisted pairs. In addition, you can get RJ45 sockets in convenient panel mount options, including an XLR connector panel footprint one with IDC wire connections. This makes prototyping very easy. You could maybe use the 4th pair for the 11.2896MHz clock if you want to use the TDA1541 (non A) reclock function.

For short distances you can probably get away with single-ended signals using series termination (100R) at the driver end to match the cable impedance and the other half of each pair grounded. I would really recommend proper differential line drivers and receivers to maintain best signal integrity though. Again, the frequency isn't high enough to need anything exotic - You could possibly even use 74HC86 XOR gates as differential drivers, 2 gates per signal with the other inputs tied high and low, one package for SDA and WS and another for SCK. There are plenty of alternative options though.

[knudsenuk]

I must admit this MCK BCK SCK WS LRCLK is all a bit confusing, there seem to be no fixed terminology.

My understanding is MCK is the highest clock frequency and is actually not a part of I2S, but a means of synchronizing a collection of ICs.
BCK is SCK and is the product of sampling frequency x 2  x 16 bits ?1.4112 MHz for cd
WS or LRCLK is the left right selection
Data is simply just that

I'm not that sure which way to go with this really. I have no interest in so called HiRes. So 44.1Kz/16 is all I need. I just wish I could find a suitable means of streaming via I2S to the aforementioned chips. There is much debate around the Pi not being able to serve up a genuine 44.1Khz BCK but when I have used my scope it is actually bang on.
So if i left the solution as PI to TDA only I can getaway without and MCK. But I think the filter does improve the sound and that needs and MCK.

There seems to be sense in having all the chips together to avoid propagation delays but that compromises space for local regulation and PSU decoupling.

I am rambling.....

[moffy]

There is a sample rate converter ic the AD1896 that might well be able to convert the sample rate  between the PI and the DAC: https://www.analog.com/media/en/technical-documentation/data-sheets/ad1896.pdf

[Gyro]

I must admit this MCK BCK SCK WS LRCLK is all a bit confusing, there seem to be no fixed terminology.

My understanding is MCK is the highest clock frequency and is actually not a part of I2S, but a means of synchronizing a collection of ICs.
BCK is SCK and is the product of sampling frequency x 2  x 16 bits ?1.4112 MHz for cd
WS or LRCLK is the left right selection
Data is simply just that

I'm not that sure which way to go with this really. I have no interest in so called HiRes. So 44.1Kz/16 is all I need. I just wish I could find a suitable means of streaming via I2S to the aforementioned chips. There is much debate around the Pi not being able to serve up a genuine 44.1Khz BCK but when I have used my scope it is actually bang on.
So if i left the solution as PI to TDA only I can getaway without and MCK. But I think the filter does improve the sound and that needs and MCK.

There seems to be sense in having all the chips together to avoid propagation delays but that compromises space for local regulation and PSU decoupling.

I am rambling.....

Yes, the signal naming can be a little confusing, a product of different digital audio chip manufacturers. In terms of true I2S, the spec is definitive, SCK, SDA and WS. The high frequency (256x sample rate in this case, in other implementations it can commonly be 384x) is commonly called MCK, apart from Philips digital audio chips of the era when it was called X-SYS.

Don't get confused between high-res (as in SACD, 24 bit, etc) and oversampling. The reason the RCD-855 sounds better than your NOS DAC is that the 4x oversampled data rate going to the TDA1541 requires much less sharp analogue audio filtering on the outputs to avoid out-of-band sampling artifacts. NOS requires a pretty much brick wall analogue filter, with lots of in-band phase issues. It it wasn't for that, multi-bit DACs would work fine at 1x sample rate. High levels of oversampling are of course essential for modern sigma-delta DACs because they are effectively single bit. The only reason that Philips adopted a low level of oversampling on a 16 bit DAC was to improve the analogue filtering. For some reason, NOS sounds immediately impressive, but ultimately tiring (speaking from long experience of my own TDA1541 based DAC designs).

Yes, the RCD-855 is a good platform (one of the best) for 'having all the chips together'. Nice metal chassis and plenty of free space. There's no particular reason that you can't implement local regulation and better decoupling. Even the existing board can be improved easily due to the design including fusible resistors on the supply to every chip (in common with other Philips based players of the era). Even changing these to inductive filters makes a difference. Many are on the same journey.

I'm rambling now!....

[knudsenuk]

We have talked in the past I think Chris. Same basic topic. The high res I am referring to is 24 bit. I have done my utmost to tell the difference and usually I can, but IMO it's no improvement and barely detectable. I think the only obvious benefit is extra dynamic headroom.

I might buy another RCD 855 and start the process again. Also my CD loading mech fell apart so it now has a Naim style magnetic "puck" and no cover. Not good with the granddaughter roaming around with an inquisitive mind!

I will stop before I inevitably start to ramble once more....


 

[Gyro]

Hah, yes. Please forgive me Richard, I had completely forgotten! I missed your final post in that thread.  https://www.eevblog.com/forum/repair/cd-player-repair/

I will adopt 24 bits when my undistorted hearing dynamic range exceeds 16 bits. At my age, that prospect seems unlikely!

Which bit broke on the loading mechanism?

[knudsenuk]

Quite a few parts, the plastic parts seemed to be very brittle. It doesn't actually bother me and it gets rid of that noise the clamping mech makes
. But I have to remember to switch it all off. HiRes is another hot topic on youtube which seems to be generally misunderstood and defended by, as Dave would say audiofools.

Like you, I think not only are my ears not up to the extra dynamic range but also my amplifiers and speakers.  I can't hear past 10Khz, which was clearly proved by some post grads working on an intern with us and complaining about the singing noise from a CRT TV. I am sure they were imagining it  I doubt they even realised it was a TV!