Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 11 October 2008 14:44:52 Andy Walls wrote:
> On Sat, 2008-10-11 at 08:53 -0300, Mauro Carvalho Chehab wrote:
> > On Sat, 11 Oct 2008 12:44:26 +0200
> >
> > Janne Grunau <j@xxxxxxxxxx> wrote:
> > > On Saturday 11 October 2008 04:08:10 Andy Walls wrote:
> > > > On Fri, 2008-10-10 at 21:32 -0300, Mauro Carvalho Chehab wrote:
> > > > > Hi Andy,
> > > > >
> > > > > On Sat, 4 Oct 2008, Andy Walls wrote:
> > > > > > cx18: Change module parameters for finer control over
> > > > > > buffer allocation
> > > > >
> > > > > It is not a good idea to rename module parameters. Anyone
> > > > > with a previous setup using the old parameters won't have the
> > > > > modules loaded after the rename.
> > > >
> > > > A very good point.  Initially this is the way I had it.
> > > >
> > > > But a user pulling my change, without asking me, then had
> > > > problems because there was no obvious indications that the
> > > > units of the module parameter had changed from 'MB' to 'number
> > > > of buffers'.  There was quite a difference for him going from
> > > > '8 MB' to '8 buffers of several kB'. :) The problem was that
> > > > the difference in units was silent unless he had actually run
> > > > modinfo.
> > > >
> > > > > I suggest you to keep the old naming.
> > > >
> > > > I'm leary about keeping the old module parameter name with a
> > > > change in units for the reason cited above.  I'm open to
> > > > suggestions on how to keep an optimal user experience though.
> > >
> > > The new module parameter name is fine since it means something
> > > different. The old parameter should stay for a couple of kernel
> > > release and print a warning that it is replaced by the new one.
>
> OK.  I can certainly work something in like this.  It's better than
> the kernel giving some minimal gripe about not being able to load the
> module.
>
> > OTOH you could
> >
> > > just compute the number of from the complete buffer size in mega
> > > bytes and the individual buffer size.
> >
> > That would be my suggestion ;)
>
> Yup, I've been down that road too.
>
> There's a hardware/firmware limit I ran across on the number of
> buffers: 63.  Staying within the hardware limits was the easy thing
> to do.  I suppose it could be overcome with some non-trivial
> bookkeeping work in the driver.
>
> As a point of reference, in the few times I've measured, buffer
> utilization for the MPEG stream never bursts past 11 buffers of 32 kB
> size (352 kB) with only one ongoing capture on my system.  That burst
> of 11 was a singular event.  I suppose if a user has a really slow
> app or really loaded system, more depth would be required.

Actually, that happened in the past with MythTV and ivtv: sometimes the 
same thread that read from video0 would start doing database accesses 
which could block the application from reading from video0 for up to 10 
seconds.

I believe that has been fixed now (database access has its own thread), 
so this should no longer be an issue.

Regards,

        Hans

>
>
> Thanks all.  I'll try to work something out.
>
> Regards,
> Andy



_______________________________________________
v4l-dvb-maintainer mailing list
v4l-dvb-maintainer@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer

[Index of Archives]     [Linux Media]     [Older V4L]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [SSH]     [Linux USB]

  Powered by Linux