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