- I2S on the UC3A3 has the limitation that the main clock of the CPU must be synchronous with the clock that drives the SSC module that implements I2C (at least this is what I can understand from the phrase: "Because the master clock must be synchronous to the sample rate both clock sources to the generic clock and to the SSC module must have the same source"
The Atmel phrase is correct. The SSC needs to be clocked by a source that is synchronous with the DAC MCLK so that the i2s signals generated by the SSC are ultimately synchronous with the DAC for synchronous clocking.
However, the *main* clock of the cpu need NOT be synchronous, and in fact is not. We need cpu to be clocked by a 12Mhz crystal (OSC0) so that it can generate the USB clock for HIGH speed USB communication with the host.
[QUTOE]
- on the AB 1.1 there are 2 clocks (24.576 and 22.5792 Mhz, the Golledge clocks), one of the two is selected (as a function of the desired sampling frequency, the biggest for 48K and multiples and the other for 44.1K and multiples)
- the selected clock is sent DIRECTLY to the DAC chip, and a divided by 2 version is sent to the CPU (or better, to the power manager, that incorporates PLLs and dividers to create an internal clock to be used by the I2S logic and the CPU).
Now, if I'm not mistaken, the I2S clock is OUTPUT by the UC3 but is unused (the DAC chip is fed directly by the selected clock), while the other signals, mainly LRCLK are generated by the I2S module with internal dividers and counters.
[/QUOTE]
The i2s clock/data are output by the SSC and to the DAC chip: TX_DATA, TX_CLOCK, TX_LRCK.
The DAC chip only gets the MCLK directly from the Golledge clocks.
My doubt is as follows:
aren't there any jitter problems on such signals?
The main clock to the DAC comes directly from the high precision Golledge clocks, and that's OK, but LRCLK and SDATA come from the UC3, and so are potentially contamined by internal digital noise ... the UC3 has lots of digital circuitry, with many many different clocks ...
As 1Audio has explained, it depends on the DAC. For the DAC's that we are using, the MCLK has to have the lowest jitter. But the i2s clocks (TX_CLOCK, LRCLK) can tolerate much higher jitter without adverse effects on the SQ.
In fact, there is another subtle effect. High jitter in the i2s clocks, especially if it is uncorrelated, may have a "spread spectrum" effect such that there may be a reduction of radiated noise from the uC side to the analog circuitry in the DAC side.
My question (to the experts) is as follows: is it possible on the UC3 to drive the I2S clock from the external? Is the sync between the "generic clock" and the clock of I2S really mandatory?
The i2s clocks and data are generated by the SSC. This ensures that the setup and data validity times are completely controlled by the SSC and therefore within the i2s specs.
It is possible to generate i2s clocks "externally", but you will probably need to use an FPGA, and you need to have another channel to transfer the audio data from the uC to the FPGA (eg memory mapped transfer etc.) Then you also have the problem of controlling the jitter of the FPGA, and handling the digital noise generated by the FPGA (and its PSU) itself etc. Even with "external" clocking, you will also need to use opto or magneto isolation. The isolation will generate jitter as well.
So ultimately one has to consider what you are trying to achieve wrt to jitter in the the i2s clocks.
My hunch is that for some DAC's, the MCLK is the key. The i2s is just for transferring the data across, and jitter in the i2s clocks does not impair SQ (and in fact may improve SQ because of the spread spectrum effect).
Alex
), next and Audio-Widged was in the list. 
