CS8412 + filterless Non-OS dual AD1865

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
gmarsh said:
If the CS8412's PLL is unlocked or your PLL is unlocked, then the SCK and nSCK signals won't be aligned. When this happens, god knows what sound your DAC will put out. It might be worth taking the unlock signals from the 8412 and PLL, and using them to mute/unmute the DACs you're using if there's no SPDIF signal.

I will make such a mute feature... I have added a flag in the circuit that goes high when PLL is unlocked.

I have made up my mind on that VCXO thing, and I am not going to make my own. I will however buy a complete module when I get my DAC mainboard done. My energy will be focused into the DAC itself, or I'll never get around to complete it...

The attached schematic shows just about where I'm currently at. The SPDIF needs to be sorted out correctly, PSU is not done, some decoupling of logic is still missing, and stuff like the mute feature and some other logics is also to come... Comments are ofcourse appreciated. :)
 

Attachments

  • i2s_dac.gif
    i2s_dac.gif
    19.9 KB · Views: 898
Re: AMIS FS6322-05

cathode_leak said:
Argh... my desire to keep digital filters out of the circuit are being threatened all the time... How the heck do I employ mute on an ADC chip without the feature built-in, without using a digital filter? Can it be done using logic on the I2S data line?
Use the clear input on the data flip-flop.

cathode_leak said:
Can anyone comment on this chip: http://www.chipdocs.com/datasheets/datasheet-pdf/AMIS/FS6322-05.html?? it's a VCXO/PLL all-in-one IC capable of delivering my desired 11.28960MHz...
That's not a VCXO, it's a cheap crystal oscillator with a bunch of PLL's for generating different clocks.

You'll need to use a proper PLL chip and a discrete VCXO. Again, AD4116 (or similar) + VCXO from raltron/etc + loop filter. Chances are you'll also need a PIC12C508 or something to configure the PLL.
 
cathode_leak said:


I will make such a mute feature... I have added a flag in the circuit that goes high when PLL is unlocked.

I have made up my mind on that VCXO thing, and I am not going to make my own. I will however buy a complete module when I get my DAC mainboard done. My energy will be focused into the DAC itself, or I'll never get around to complete it...

The attached schematic shows just about where I'm currently at. The SPDIF needs to be sorted out correctly, PSU is not done, some decoupling of logic is still missing, and stuff like the mute feature and some other logics is also to come... Comments are ofcourse appreciated. :)

Why all the logic on the 8412 receiver ip? Why not put the Rx tranny staight on the ip pins like in the data sheet?
 
This is h*ll.. I'm too sleepy to figure out wether ERF will stay high (triggered by the error) long enough so that it will trigger the AND gate when attempting to read the error code... ERF high indicates error... E0, E1, and E2 all three of them high indicates unlocked PLL... And they (E0 E1 E2) can ofcourse not be read until SEL is low either... nah.. tomorrow.. :sleep:
 
The HC4040 will be an integral part of your PLL - you can't generate 11.289MHz or whatever and divide it down in your circuit, unless you bring your divided nSCK back into your PLL.

I'm having trouble tracking down a 11.289 or 22.579 VCXO from a common supplier (digikey/mouser/etc...). Multiples of 44.1KHz are hard, multiplies of 48KHz are easy.
 
CraigBuckingham said:


I thought it was your design.

So are you saying you don't know why you have done it that way?


No, I was just trying to make you figure it out... ;) Why not use just the tranny like in the datasheet? Because I wanted the SPDIF treated in a balanced manner (for many reasons), because of the CS8412 schmitt-trigger... There are alot of reasons not to do as suggested in the datasheets, most reasons are related to the crappy nature of the SPDIF standard... But I do not know to much about it yet, Jocko has helped me getting started, but I will still need to do some work on the input.

I can suggest some recommended reading:
http://www.diyaudio.com/forums/showthread.php?s=&threadid=3282&highlight=6111
 
gmarsh said:
The HC4040 will be an integral part of your PLL - you can't generate 11.289MHz or whatever and divide it down in your circuit, unless you bring your divided nSCK back into your PLL.

Ofcourse.. :headbash: :h_ache:

gmarsh said:
I'm having trouble tracking down a 11.289 or 22.579 VCXO from a common supplier (digikey/mouser/etc...). Multiples of 44.1KHz are hard, multiplies of 48KHz are easy.


I have noticed. There is, ofcourse, Guido's VCXO...
 
But there might be a good idea to include a counter in the circuit anywayz, to retrieve master clocks from devices not using 44.1KHz sampling freq (eg. some soundcards) since a 11.2896MHz PLL-VCXO will be unable to lock on them...? Wiith jumper programmable selection between output pins for full flexibility...?
 
cathode_leak said:
But there might be a good idea to include a counter in the circuit anywayz, to retrieve master clocks from devices not using 44.1KHz sampling freq (eg. some soundcards) since a 11.2896MHz PLL-VCXO will be unable to lock on them...? Wiith jumper programmable selection between output pins for full flexibility...?
Thing is, the PLL needs to compare the edge of nSCK to the edge of the incoming SCK in order to keep them in phase. If you generate 16*SCK and then divide that by 16 using an outboard divider, then your output frequency would be OK but your output phase would be ambiguous with respect to the incoming SCK, unless you find a way to make sure the PLL's N counter and the outboard divider will overflow simultaneously.

With an adjustable output divider, to support the whole spectrum of audio sample rates (44.1/88.2/176.4, 32/48/96/192) at 32 bits, you'd need a 1.806GHz VCXO (good luck getting that made)... And to support 44.1/48 at 16 bits, you'd need a 225.792MHz VCXO. Then you'd need a high speed dividier after it. This won't be fun to design, and paying NRE costs for the custom VCXOs won't be fun either. Using two separate VCXOs (44.1/48) with a selector makes a lot more sense.

This is why the CS8412 contains a regular VCO. :D
 
I get the picture :D

I only need 44.1KHz, really, so no space-industry-top-dollar-custom-components for me :D

A question... I've seen people add small resistors (<100ohms) on the data/clock lines of the ADC chips, after the logics... what is the purpose of this, and should I concider it in my circuit?

Also, I'd like to hear what people thinks are suitable decoupling for logics in the circuit. I think my VHC logics (the critical ones) will have independent shunt regulators, while the error handling/mute logics (probably HC code) will have one shared shunt regulated supply..

I think the CS8412 no lock error flag will work as is now.. Any feedback on it would be highly appreciated..
 

Attachments

  • i2s_dac.gif
    i2s_dac.gif
    18.5 KB · Views: 639
ERF will go high on error, trigger the NPN transistor (I'm thinking BC547) wich will set the SEL pin low. With SEL low, the E0 E1 E2 pins will provide error information...

But how long does the ERF pin stay high on error? when it goes low again, SEL goes high (by the NPN transistor shutting down), and errors will be reset after 8 cycles.. but with the current logic I need to read E0 E1 E2 pins error information while ERF is high (the cycle after SEL is set low I suppose?).., also the Mute feature will endure for ERF's entire stay at high...

quote from CS8412 datasheet
If an error occurs (ERF = 1) while using one of these formats (M3=0, normal modes), the previous valid audio data for that channel will be output. As long as ERF is high, that same data word will be output. If the CS8412 is not locked, it will output all zeroes.

Should I maybe simply use ERF flag to mute, regardless of what the error is? The errors represented by ERF=high is;

0 0 1 Validity Bit High
0 1 0 Confidence Flag
0 1 1 Slipped Sample
1 0 0 CRC Error (PRO only)
1 0 1 Parity Error
1 1 0 Bi-Phase Coding Error
1 1 1 No Lock

(bits represents state of E0, E1, E2)

Are all these errors reason good enough to mute?
 
Hey Cathode,
What’s the object of your DAC design: To make everything as complicated as possible? You rely on the PLL in the CS8412 to recover the bit clock, but because that clock is not good enough, you send it to another PLL. To do what? GIGO. Then you use the reconstituted and regurgitated bit clock to reclock the word clock, which is the critical clock for the DAC chips you are using.

Look at the datasheet. SCLK is MCLK divided by four. MCLK is the output of the VCO, which is spec’ed at 200 psRMS jitter. But that’s not the whole story. Look at the spec for Tsfdm (on page 4). It says SCLK has +/- 20ns jitter with respect to FSYNC. The question is: Which clock, FSYNC or SCLK, is more accurate and which clock are you going to trust to strobe your DAC chips?

SCLK is derived from the PLL, which is tracking the S/PDIF data stream. We already know that clock has a lot of jitter and it is modulated by the changing data patterns in the S/PDIF signal. On the other hand, FSYNC is generated by the subframe preambles, which are extracted at times when the intersymbol interference is at a minimum.
This provides a sample frequency clock that is as spectrally pure as the digital audio source clock.
I’d put my money on FSYNC.

Of course, if you don’t trust the CDP to get the timing of the preambles right, you should put the oscillator of your choice in the DAC, slave the CDP to it and run the CS8412 in mode 1. That way the master clock without PLLs or reclocking voodoo generates every clock edge.
 
Hi Ulas. Thanx for your input. You are certainly pointing out a number of interresting aspects... :scratch2: I will have to go and buy cigarettes.. and then read through what you say again.. I'm not sure if I understood everything correctly :scratch1: but I'd like to get to the bottom of it as the phrase goes.. People; if you have remarks or opinions please comment on Ula's suggestions! GM?
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.