On Sun, Jan 07, 2007 at 02:08:48PM -0500, Daniel Kristjansson wrote:
>On Sun, 2007-01-07 at 17:02 +0000, MythTV wrote:
>> Talking about the CiHandlerLoop: currently there is a usleep(250) in
>> there, with some debugging code I found that the loop is executed approx.
>> 950 times/sec on my machine, which seems a bit excessive.
>> I've tried bumping the usleep to 2500, 10000 and 90000 (so 2.5, 10 and 90
>> ms precision), and there seems to be no ill effects. Do you know why the
>> current value is so low? Perhaps the usleep should be changed?
>I've just bumped it up to 10 ms. In all honesty the CAM module
>is not very actively maintained. It's the only DVB code in
>MythTV which is still just a wrapper around VDR code. This
>is just because no one has stepped up to clean this up and
>none of the committers uses a CAM. We really shouldn't have
>a tight usleep loop like this, but rather we should trigger
>processing with a QWaitCondition for things like the PMT update
>plus a longer usleep (or rather a QWaitCondition timeout)
>to take care of things like polling the CAM module.
Yes, that seems like a reasonable approach, it requires a much larger
rewrite though since the timeout differs at all stages depending on
where in the state machine we are (e.g. if a status poll has been sent
to the CAM, the timeout is 350 ms while the timeout until the next poll
after a succesful poll is 100 ms).
The optimal solution would probably be one that combined a poll (for
incoming data from the module) with a state-specific timeout and
support for other interrupting events (such as a new PMT or TDT).
I think that some inspiration can be found in the libdvben50221 library.
--
David Härdeman