On Thursday 06 November 2008 05:47:08 Andy Walls wrote:
> 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.
Reviewed-by: Hans Verkuil <[EMAIL PROTECTED]>
Looked good to me!
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
