Andy Walls wrote: > On Sun, 2009-07-19 at 18:40 +0530, Ravi A wrote: > >> Andy Walls wrote: >> >>> On Sat, 2009-07-18 at 21:31 -0400, Andy Walls wrote: >>> >>> >>>> On Sun, 2009-07-19 at 06:53 +0530, Ravi A wrote: >>>> >>>> >>> >>> >>>>>> >>>>>> >>>>>> >>>>> Hi Andy, >>>>> >>>>> I just checked, it still has the same problem. Just to verify, I went >>>>> back to the 82a264ea2784 version again and that is smooth. Maybe you can >>>>> decide to leave out the cx25840 changes after testing on your PVR150 >>>>> too, to double confirm. >>>>> >>>>> >>>> I just think I figured out the problem. The I2S master clock has to be >>>> running at 384 clocks per sample. My computations are ensuring it's 384 >>>> clock per sample for Broadcast decoder (TV tuner audio) output, and 256 >>>> clocks per sample on Line in I2S input. The reason I did this was that >>>> on the input side of the CX2584x the decoder uses 384 and the I2S input >>>> uses 256. This is likely the problem. >>>> >>>> I'll figure out new numbers and try again.... maybe tomorrow. :) >>>> >>>> >>> OK, I lied. The latest change for the cx25840 module is at >>> >>> http://linuxtv.org/hg/~awalls/ivtv >>> >>> I haven't tested it, but I will have to to make sure Tuner audio still >>> works. Please test line in audio if you can. >>> >>> (now I'm going to bed...really...) >>> >>> regards, >>> Andy >>> >>> >>> >> Hi Andy, >> >> You were right on time for me to test it as soon as I woke up :) >> This version seems much better. The skip/jump has gone away! >> > > Good to hear. > > >> However I >> notice some video/audio dropouts after a few seconds of playing, and the >> "too many video packets in buffer" messages too. The good news is, the >> 82a264ea2784 version is also showing these dropouts - I am certain it >> was smooth before, so a bit puzzled as to why I am seeing these dropouts >> now! >> > > It's likely a system level issue. Is there any device sharing the same > PCI interrupt line as the CX23416 with a linux driver attached to it. > > $ cat /proc/interrupts > > If ivtv is sharing an interrupt with a linux device driver that doesn't > always respond promptly, that would be a source of dropped buffers. > > That's just a first guess. There could be other factors. > > > > >> But anyway the latest PLL VCO change version seems same as earlier >> versions now. I have not compared with 32KHz audio sampling yet though. >> > OK. > > > >> Do let me know if there is anything I can check to eliminate or isolate >> the driver settings as the cause for the audio/video dropouts. >> > > 1. Blacklist/unload any module that's sharing the PCI interrupt with the > CX23416 > > or > > 2. Move the CX23416 card to another slot so that it gets a different > interrupt line. > > > > > >> The >> machine itself and components are fast and I am able to play 1080p video >> from local disks smoothly. >> >> It might help if there can be another independent testing on this version. >> > > Yes, that was my plan for today. > > I also wanted to look at the WM8379 configuration today. > > Unfortunately my wife just informed my that we have a non-trivial amount > of water leaking in the laundry room, so I'll likely be spending the day > fixing whatever is broken. > > Regards, > Andy > > >> Regards >> Ravi >> > > >
Hi Andy, The card was sharing an IRQ with a USB controller. I disabled USB from BIOS and ensured the card gets dedicated IRQ. But the problem still persists. It is also pretty consistent now, despite several reboots and tweaked settings I could not get rid of it. I am inclined to think the clock settings or whatever else in the card may not be fully alright yet. Your testing should be able to confirm - but ofcourse we will wait for you to patch the laundry room pipes before patching any more code! Also I checked with 32KHz audio sampling frequency - there was some strong weird tone shifting. Regards Ravi _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
