Analog Tuner Mystery

NTDEV
1

Can anyone throw any light on this?

I have developed an analogue TV capture device, controlling real hardware, that gives the appearence of working correctly in WIndows Media Center on Windows 7.

When Live TV is started, the driver gets the IOCTL messages to change the pin KSSTATE on the capture filter, in the right order (i.e stop->acquire, acquire->pause, pause->run).

If I change channel, I get the IOCTL_KS_PROPERTY calls to set the new frequency, but I do not see any IOCTL_KS_PROPERTY calls to set the KSSTATE of the pins back to stop or even pause. Does this mean that WMC changes channel with the output pins in KSSTATE_RUN?

Another mystery: The driver gets 2 IOCTL_KS_WRITE_STREAM calls for each channel change. One before the frequency is set and one after. These are VBI processing calls sent as KS_TVTUNER_CHANGE_INFO structures with the dwFlags member set to KS_TVTUNER_CHANGE_BEGIN_TUNE and the second call with dwFlags set to KS_TVTUNER_CHANGE_END_TUNE. If I handle the call by completing the irp, then WMC allows channel changes using the +/- buttons. If I ignore the IOCTL and pass it through to KS, then I get a “Tuner Error” message in WMC and no channel change happens. This is the case even if I rebuild the driver without the VBI pin on the capture filter. Why should this be? The VBI pin, when present, has the pin flag KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY. Other than that, it is virtually unchanged from the SWTuner sample in the WDK.

Clive

2

xxxxx@taycon.co.uk wrote:

When Live TV is started, the driver gets the IOCTL messages to change the pin KSSTATE on the capture filter, in the right order (i.e stop->acquire, acquire->pause, pause->run).

If I change channel, I get the IOCTL_KS_PROPERTY calls to set the new frequency, but I do not see any IOCTL_KS_PROPERTY calls to set the KSSTATE of the pins back to stop or even pause. Does this mean that WMC changes channel with the output pins in KSSTATE_RUN?

Yes. Does that surprise you? An analog TV capture device shouldn’t
need to restart just because the channel changed. The delivery of
frames is not affected.

Another mystery: The driver gets 2 IOCTL_KS_WRITE_STREAM calls for each channel change. One before the frequency is set and one after. These are VBI processing calls sent as KS_TVTUNER_CHANGE_INFO structures with the dwFlags member set to KS_TVTUNER_CHANGE_BEGIN_TUNE and the second call with dwFlags set to KS_TVTUNER_CHANGE_END_TUNE.

Right. I believe these are sent by the ksproxy wrapper around your
tuner driver, to your capture driver.

If I handle the call by completing the irp, then WMC allows channel changes using the +/- buttons. If I ignore the IOCTL and pass it through to KS, then I get a “Tuner Error” message in WMC and no channel change happens. …

I’m not sure what you mean by “ignore the ioctl and pass it through to
KS”. Are you intercepting these before KS gets them? Usually, those
requests get converted into calls to the Process handler for your input
pin. You handle them there, then mark the frame as complete by calling
KsStreamPointerUnlock with Eject=TRUE.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thanks, Tim.

> If I change channel, I get the IOCTL_KS_PROPERTY calls to set the new
frequency, but I do not see any IOCTL_KS_PROPERTY calls to set the KSSTATE of
the pins back to stop or even pause. Does this mean that WMC changes channel
with the output pins in KSSTATE_RUN?

Yes. Does that surprise you? An analog TV capture device shouldn’t
need to restart just because the channel changed. The delivery of
frames is not affected.

We had expected some state change in the video/audio output pins to avoid the channel change noise. I checked against the Hauppauge HVR-900 hybrid USB tuner after I had posted my request, and certainly saw no evidence of that happening.

> Another mystery: The driver gets 2 IOCTL_KS_WRITE_STREAM calls for each
channel change. One before the frequency is set and one after. These are VBI
processing calls sent as KS_TVTUNER_CHANGE_INFO structures with the dwFlags
member set to KS_TVTUNER_CHANGE_BEGIN_TUNE and the second call with dwFlags set
to KS_TVTUNER_CHANGE_END_TUNE.

Right. I believe these are sent by the ksproxy wrapper around your
tuner driver, to your capture driver.

> If I handle the call by completing the irp, then WMC allows channel changes
using the +/- buttons. If I ignore the IOCTL and pass it through to KS, then I
get a “Tuner Error” message in WMC and no channel change happens. …

I’m not sure what you mean by “ignore the ioctl and pass it through to
KS”. Are you intercepting these before KS gets them? Usually, those
requests get converted into calls to the Process handler for your input
pin. You handle them there, then mark the frame as complete by calling
KsStreamPointerUnlock with Eject=TRUE.

They were being intercepted, as I wanted to document all calls made to our DeviceControlDispatch function over and above our own IOCTLs. Initially, I was only interested in the IOCTL_KS_PROPERTY calls, especially to see what property get/set calls were made to make sure that I had everyhting catered for. All other calls were logged as “Unhandled IOCTL 0x%08X”. I was intrigued to see several IOCTL_KS_WRITEs and IOCTL_KS_READs and wanted to know more about them, even if it was just looking at them under WinDbg.

By “ignore the ioctl and pass it through to KS”, what I meant was that the IRP was passed onto the DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] hooked at DriverEntry time, rather than being completed by DeviceControlDispatch. Sorry it was badly worded. The hooked device control function returned 0xC0000010 (STATUS_INVALID_DEVICE_REQUEST) for the writes and 0x00000103 (STATUS_PENDING) for the reads.

It was a bit tricky testing the channel change functionality, as I don’t have access to an NTSC feed here, in fact the local PAL feed is due to be switched off soon (the Dover transmitter area is one of the last to be switched over). My colleagues had access to an ATSC set top box, and could only check it with the menu on the NTSC RF output - so only one channel.

It now seems to be sorted out.

Clive