Confused about Kernel Streaming / DShow clocks...

Hi folks,

Just a quick post to see if someone can clarify my understanding of kernel
streaming clocks.- I think I've got the basics, but there are a few loose
ends...

I've got a multimedia card with separate audio and video capture drivers
written under the stream class driver. At the moment, the captured audio &
video has a habit of drifting out of sync, so I need to put clock support
into the drivers. Additionally, the hardware has 27 MHz counter that can be
queried to give me a very accurate clock source.

As I currently understand it:

a) I need to get both audio and video capture drivers to support being a
master clock.
b) I need to get the drivers to be able to timestamp samples based on the
master clock for the graph (which might be themselves, or might be from
somewhere else).

Here's where I have a few questions...

Q'n 1. It seems that there seem to be several ways of doing "a)" and "b)"

- MSDN seems to indicate that I can do a) by including information in my
HW_STREAM_OBJECT indicating that I can act as a master clock, by including
appropriate clock support flags, and a callback routine (HW_CLOCK_OBJECT).
- If I do that, then my clock support is going via the stream class driver.
It then seems the the "similar" way of implementing b) is to use the
"StreamClassQueryMasterClock" routine, using the clock handle passed to my
driver via SRB_INDICATE_MASTER_CLOCK.

Make sense so far?

If so, then why is there also a whole load of KS Property stuff, which
provide similar functionality? It seems that if I want to provide a master
clock source via the KsProperty route,. then I'll have to implement
KSPROPSETID_Clock, and also KS_PROPERTY_STREAM_MASTERCLOCK.

Do I have to do both of these, or is it an either/or proposition, with the
stream class driver doing some behind the scenes work for me in the first
case?

Qn 2: If I have the two filters running, and both can provide a master
clock, then the audio capture driver will provide the master clock of the
graph - so I need to get the other driver to timestamp samples based on the
audio driver. StreamClassQueryMasterClock would seem to do the job if I want
to use stream.sys, however, it's asynchronous, and it doesn't seem sensible
to try and perform such a query every time a get a media sample. Any
suggestions on strategies for getting the drivers to query the master clock
at intervals and then interpolate? How is this normally done?

Qn3: If I was to use the property set approach, instead of
StreamClassQueryMasterClock, it seems that I need to get on driver to get
hold of the direct call interface (KSPROPERTY_CLOCK_FUNCTIONTABLE)
advertised by the other driver... how do I do that?

thanks in advance,

Martin Harvey.

Geraint
Sat Sep 18 05:49:12 CDT 2004

It's been a few years, so I'm a bit rusty, but perhaps I can remember a few
things that would help.

If you are a stream class minidriver, you implement the clock using the
HW_STREAM_OBJECT entries that you mention, and you will query the clock
using StreamClassQueryMasterClockSync. The stream class drivers
implementation is layered on top of KS, so it will handle the KS_ stuff for
you.

A few pointers from memory:

-- you need to implement the event function as well, for
KSEVENT_CLOCK_POSITION_MARK and KSEVENT_CLOCK_INTERVAL_MARK. A clock
triggers these events as well as reporting the time.

-- remember that the time on a KS clock is what a DirectShow clock would
think of as Stream Time, not absolute reference time.

-- you don't get an "indicate-clock" if you get an "open clock" srb, so when
getting the time, you need to check if your clock is opened first and call
it directly.

-- the normal way to timestamp is to get the performance counter at
interrupt time, then at DPC time you call StreamClassQueryMasterClockSync.
This reports the clock time and the current performance counter time so you
can extrapolate to what the stream time was at interrupt.

G

"Martin Harvey (work)" <m.harvey@nospam.snellwilcox.com> wrote in message
news:%232F0aNMnEHA.3076@TK2MSFTNGP15.phx.gbl...
> Hi folks,
>
> Just a quick post to see if someone can clarify my understanding of kernel
> streaming clocks.- I think I've got the basics, but there are a few loose
> ends...
>
> I've got a multimedia card with separate audio and video capture drivers
> written under the stream class driver. At the moment, the captured audio &
> video has a habit of drifting out of sync, so I need to put clock support
> into the drivers. Additionally, the hardware has 27 MHz counter that can
> be
> queried to give me a very accurate clock source.
>
> As I currently understand it:
>
> a) I need to get both audio and video capture drivers to support being a
> master clock.
> b) I need to get the drivers to be able to timestamp samples based on the
> master clock for the graph (which might be themselves, or might be from
> somewhere else).
>
> Here's where I have a few questions...
>
> Q'n 1. It seems that there seem to be several ways of doing "a)" and "b)"
>
> - MSDN seems to indicate that I can do a) by including information in my
> HW_STREAM_OBJECT indicating that I can act as a master clock, by including
> appropriate clock support flags, and a callback routine (HW_CLOCK_OBJECT).
> - If I do that, then my clock support is going via the stream class
> driver.
> It then seems the the "similar" way of implementing b) is to use the
> "StreamClassQueryMasterClock" routine, using the clock handle passed to my
> driver via SRB_INDICATE_MASTER_CLOCK.
>
> Make sense so far?
>
> If so, then why is there also a whole load of KS Property stuff, which
> provide similar functionality? It seems that if I want to provide a master
> clock source via the KsProperty route,. then I'll have to implement
> KSPROPSETID_Clock, and also KS_PROPERTY_STREAM_MASTERCLOCK.
>
> Do I have to do both of these, or is it an either/or proposition, with the
> stream class driver doing some behind the scenes work for me in the first
> case?
>
> Qn 2: If I have the two filters running, and both can provide a master
> clock, then the audio capture driver will provide the master clock of the
> graph - so I need to get the other driver to timestamp samples based on
> the
> audio driver. StreamClassQueryMasterClock would seem to do the job if I
> want
> to use stream.sys, however, it's asynchronous, and it doesn't seem
> sensible
> to try and perform such a query every time a get a media sample. Any
> suggestions on strategies for getting the drivers to query the master
> clock
> at intervals and then interpolate? How is this normally done?
>
> Qn3: If I was to use the property set approach, instead of
> StreamClassQueryMasterClock, it seems that I need to get on driver to get
> hold of the direct call interface (KSPROPERTY_CLOCK_FUNCTIONTABLE)
> advertised by the other driver... how do I do that?
>
> thanks in advance,
>
> Martin Harvey.
>
>

Martin
Mon Sep 20 15:24:32 CDT 2004

On Sat, 18 Sep 2004 11:49:12 +0100, "Geraint Davies"
<geraintd@_NO_THANK_YOU_REALLY_gdcl.co.uk> wrote:

>It's been a few years, so I'm a bit rusty, but perhaps I can remember a few
>things that would help.

Many thanks for the prompt answer, look forward to seeing you on
Friday :-)

MH.