[linux-dvb] FE_CAN_MUTE_TS and delays in FE_SET_FRONTEND

[Andrew de Quincey <adq_dvb@lidskialf.net>]

Hi, I've been investigating how to remove the delay in FE_SET_FRONTEND.

This because of the following piece of code in 
dvb_frontend.c/dvb_frontend_ioctl():

	if ((cmd == FE_SET_FRONTEND) && (err == 0)) {
		dvb_frontend_wakeup(fe);
		err = wait_event_interruptible(fe->wait_queue, fe->state & ~FESTATE_RETUNE);
	}

This was added to get round the problem where the frontend was already locked. 
Cards would call SET_FRONTEND, then create a demux filter really fast, and 
would end up getting old data from the previous lock because the frontend 
thread had not yet kicked off the retune.

This code could be removed for most frontends, but there is a problem with 
those which have the FE_CAN_MUTE_TS flag (which means it doesn't output 
rubbish when it isn't locked onto a signal).

During FE_SET_FRONTEND, the code calls dvb_frontend_add_event() with a status 
of 0, to indicate that the frontend is no longer locked.

For frontends which do _not_ have the FE_CAN_MUTE_TS flag, it also calls:

		fe->frontend.notifier_callback(fe->status, fe->frontend.notifier_data);
(where fe->status is 0).

This tells the demuxer that the frontend is not locked, and any data it sees 
is likely to be rubbish, and to ignore it.




The problem is that just before the above call, there is the following:
	if (!(s & FE_HAS_LOCK) && (fe->info->caps & FE_CAN_MUTE_TS))
		return

This is causing the problem: although the frontend is already locked, we 
really don't want to see any data from it until the FE_SET_FRONTEND has 
completed locked on to the new frequency. 

I'd suggest removing the FE_CAN_MUTE_TS test above. Is there any disadvantage 
to doing this?


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.