I have solved problem. It seems that two consecutive davinci i2c writes need to have some delay in-between. After adding 10ms delay before each write, it works fine. After changing the pll1705 output clock, some extra delay is required before exiting davinci_set_samplerate, don't know why, but if without such delay (I tried 100ms), the audio buffer seems to hang. Close and reopen the device will make it work again. I guess the delay is to wait for the clock to be stable or something.
One curious question, I just wonder why the driver developer didn't use this method. It is much cleaner and easier, without any rounding issue, and we can spare one PLL inside aic33. Is there any downside of doing this? I haven't found any yet. -----Original Message----- From: [EMAIL PROTECTED] incidsp.com [mailto:[EMAIL PROTECTED] inux.davincidsp.com] On Behalf Of #ZHENG LEI# Sent: Tuesday, January 30, 2007 4:33 AM To: [email protected] Subject: AV Sync Problem (Trouble Using I2C Expander) Hi: I've been chasing the AV sync problem for over a week. After numerous trials, I finally confirmed that it's not caused by my sync algorithm, but either the video frame rate is too slow, or the audio clock rate is too high. After digging into audio driver source code, I spotted the MCLK truncation problem. I wanted to solve this problem by programming the PLL1705 through I2C expander with address 0x39 (U18). I wonder why the original code doesn't do that, instead it uses some odd 22.5MHz as MCLK and use AI33's PLL to get the sample freq. Well, I later found out that there is a new patch fixing the problem by changing MCLK to 22.5792. That's much more accurate, but still has rounding problem. So, with a long enough movie, we still face the AV sync problem. Why not just rely on PLL1705 to generate the reference frequency (48KHz or 44.1KHz), and simply turn off the PLL on AIC33 and only use a constant divider. This way, we don't have any rounding issue. The problem is, it seems that I cannot change the I2C expander output value. The I2C expand somehow remains in its initial state after power-on reset, i.e. all bit set to one (by the way, according to the datasheet of PLL1705, this is an invalid input combination. But it seems that with this invalid input, we get the 22.5792MHz from SCKO2). Reading or writing to the I2C expander do not have any effect, but without any error either. Does anybody know why? _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
