On Wed, 2008-11-05 at 00:30 -0500, Jeff Campbell wrote: > > > On Tue, Nov 4, 2008 at 12:54 AM, Jeff Campbell <[EMAIL PROTECTED]> > wrote: > With the patch applied and the module installed > under /lib/modules/..... > > # modprobe -r cx18 > # modinfo cx18 > # modprobe cx18 enc_mpg_bufsize=8 enc_mpg_bufs=63 > > 63 buffers of 8 kB each. Not a lot of buffer depth, > but with the > default buffer size (of 32 kB IIRC) you didn't get > very deep buffer > usage anyway. I've only observed 11 buffers x 32 kB > as a maximum burst > from the chip when MythTV or mplayer couldn't keep up. > > > Hi Andy, > > I got your patch compiled and loaded. > > My audio dropouts when watching the multicast via vlc are > still about 1 per every second or so, but the number of > complaints in the vlc messages window is way down, so it > definitely has made an improvement but there is a still a > material issue. > > I'd like to help, is there any testing I can do and document > to be of assistance? > > -Jeff > > I have installed mplayer from the debian multimedia repos and have > tried your suggestion of the -cache 16348 option. For various reasons > I can't play video on the machine right now (it is console only) but I > can listen to the audio jack so I did > > # mplayer -cache 16384 /dev/video0 > > -The stream starts at 20% cache fill,so 3.2M in this case > -The cache lasted almost exactly 2 minutes before the audio drops > stated due to a starved buffer. This results in the same effect we're > seeing playing the audio directly from /dev/video0. > > This was with the v4l repo driver, not your patched one that allows > more buffer adjustments. > > I was not able to get any materially better performance by adjusting > the buffers in that branch that you sent. > > What else should I try to help chase this down?
Jeff, Well, there's not much to be done at the moment. I know the problem is a non-uniform rate of buffers being received from the CX23418 chip. Until I can determine how to make the buffers come at a uniform rate (like 1 frame per second), the best that can be done is to give the chip smaller buffers and fix up the driver mailbox handling as much as possible. Which leads me to ask if you would be so kind as to test my latest changes at http://linuxtv.org/hg/~awalls/cx18-bugfix I have made numerous changes in how the interrupts and mailboxes are handled. I didn't achieve my goal making the dual capture problems go away, but my (wishful?) perception is that unbuffered analog capture is much better. Hans, Could you please glance at my latest changes? I changed the workqueue to the kernel default workqueue as you suggested. I also added mutexes for the outgoing command mailboxes, changed outgoing mailbox ack's not to be so picky about what they ack'ed, and changed polling for incoming acks to now wait on waitqueues instead. With all that, I suspect I screwed something up. :) Removal of the "in_atomic()" checks was most worrying, followed by the length of the timeout for "wait_event_interruptable_timeout()" and the behavior on timeout or interruption of the wait. Regards, Andy _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
