Syncing I2S on SDATA_OUT with TDM8 on SDATA_IN

Hello PhillipJ,

There is no way to actually synchronize the internal counters that divide down the master clock. So the internal LRCLK will be the correct frequency and will not drift but there will be an arbitrary phase error because you cannot control when it starts to count to divide down to the LRCLK rate.

Also there is no internal path for the serial input port clock domains to the serial output clock domains. So slaving is only among the input or the output but not both from one clock pin. The workaround is that you need to "Y" the bitclock and LRCLK from the Ethernet source and run it to one of the input ports and one of the output ports. Then set the other ports to slave off of that port.

So if you connect it to serial port 0, then set serial output port zero to be a slave, then set the other two serial output ports to slave off of serial port 0.

It seems like you have done everything else correctly by setting the start pulse to the incoming LRCLK.

Let me know if that does not work.

Dave T

Hi Dave, thanks for the reply and sorry for not getting back to you sooner. I can't 'Y' connect the bitclk from the Ethernet source as it is 256x the frame rate for TDM8 and my output ports would need only 64x; but by 'Y' connecting the LRCLK only it seems to work OK. I set the output port to be Slave to the incoming LRCLK but master of it's own bitclk.

I have had a few instances of powering up and getting horrible noise coming out which to me sounds like out-of-sync audio bit streams but checking with the scope shows the data is correctly sync'ed to the LRCLK so I wonder if the core is somehow loading (or unloading) data from/to the serial ports at the wrong time. I have sync'ed the core to the frame rate of serial inout port 0, but I do know that the device driving these ports is supplying signals before the ADAU1452 is up and running it's program, could this cause the audio to be un-sync'ed ?

Thanks as always for your help

PhilipJ

PS: is it possible to say where in a frame the input ports are read and the output ports are written ? Just my curiosity to know how things are working internally...

Hello PhillipJ,

I just spent about 45 min typing a long response to you with lots of details and when I clicked Reply there was an error and I was logged out of the forum! All was lost!

So this will be a little shorter and more to the point.

I think the solution will be to use Clock Generator 3. I have not used this feature much (there is so much that this part can do and this application is a little unusual). I do not have the time to mock this up in the lab and now I have 45 min less time! So keep in mind that it might not work but I think it is a good thing to try. I feel confident it will work and this is pretty much why this was designed into this part.

The register details are on page 114 in the Rev D datasheet. It is register 0xF026.

Set this register to the one of the serial input ports as a clock source. I think port IN0 is the one you are using to connect the clock from the network.

Then set the numerator register 0xF025 to the value of 1024. This should produce an output locked to the LRCLK rate. It might have a slight phase difference but it will follow the LRCLK. Since the numerator is 1024 and it will be divided by 1024 then there should not be any jitter in the clock.

Then you set the serial output ports to use clock gen 3 and fs would be the base rate to use. Then it will divide down the LRCLK rate that it multiplies by 1024 back down to the proper bit clock rate.

Give this a try.

Sorry, that I will try to reply about your other curiosities at another time.

Dave T

Hi Dave,

thanks for the trouble you have taken (I know how you feel when something trashes the time you've spent and you have to start again :-( ). I will try what you suggest in a while and report my results back. At the moment, the arrangement I have is working most of the time, just occassionally when I boot-up the audio is badly distorted. My current testbed is probably applying the serial port signals before the core is up and running (I think this is not recommended ?). My final design will take care of this and gate these signals off until the core is running properly...

I look forward to hearing your comments about how the core syncs up and when, in a cycle, it reads/writes the IO streams. I understand the demands on your time, I'll be patient :-)

Best regards

PhilipJ

Hello Phillip,

Applying the serial port signals before the DSP is fully booted should not cause any issues. In a way it is good because once the core is started then it will start getting the frame interrupts right away since you are setting the start pulse to the incoming LRCLK.

The only place it is not good to have clocks going early is with the DACs. It will put out DC at first since the data in the memory will be random data until the core starts stuffing new data into the memory position. If you are muting the DACs themselves then it is not that big of a deal. You just have to wait long enough for good data to be processed through all the filters in the DAC. I am assuming it is an oversampling DAC.

Dave T