We are having a large problem developing a BDA driver. The source of this
problem is that the documentation for writing a BDA driver explains what
everything does, but not what actually happens in terms of successfully
instancing a filter that will be used by Media Center.

This makes debugging impossible as very little of our code actually runs
before Media Center decides not to acknowledge our device.

Is the source code for Media Center available under some license offered by
Microsoft?

Otherwise, does anyone have a method to successfully diagnose graph building
and filter caps problems?

Re: Can the Media Center source be aquired? by Tim

Tim
Thu Apr 19 00:40:53 CDT 2007

Alex Faucher <AlexFaucher@discussions.microsoft.com> wrote:
>
>We are having a large problem developing a BDA driver. The source of this
>problem is that the documentation for writing a BDA driver explains what
>everything does, but not what actually happens in terms of successfully
>instancing a filter that will be used by Media Center.
>
>This makes debugging impossible as very little of our code actually runs
>before Media Center decides not to acknowledge our device.

Correct. It is an enormous pain in the butt. Media Center is an
absolutely dreadful environment for a driver developer. I've made two
ventures there, and I may actually decline the next opportunity that
presents itself.

What ARE you seeing? Are you getting loaded in the capture graph at boot
time?

>Otherwise, does anyone have a method to successfully diagnose graph building
>and filter caps problems?

The first step is to make sure your driver works in a non-MCE graphedt,
where things are more predictable. After that, make sure your MPEG2
encoders are certified for MCE; that's another common failure.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Re: Can the Media Center source be aquired? by AlexFaucher

AlexFaucher
Thu Apr 19 11:12:02 CDT 2007

First of all, thanks for the response.

I used the BDA sample as a base. My topology is a tuner-demod filter that
spits out mpeg2ts in system memory on the out pin.

In graphedit I can build a graph using atsv if my demod is 8vsb or the
gerenic ms network provider if my demod is QAM. This allows me to play the
video for approx 5 seconds before graph edit triggers data execution
prevention.

In media center I with an 8vsb demod I can get my tuner recognized and media
center sees strong signal strength but when I go to play live tv, the graph
runs and delivers video but after 30 seconds of black screen it says there is
no signal.

If I change the demod to QAM, media center creates my filter, pins, then the
debugger spits out cannot use WMDRM while the debugger is attached. Then
tears down the filter. It does this 5 or 6 times. Then media center claims
there is no tuner attached. I see the same message once or twice as an 8vsb
device but the 3rd time it always builds a graph successfully.

I don't know how to debug code that runs outside and away from my own. All
my code runs with success, the failure is external.

"Tim Roberts" wrote:

> Alex Faucher <AlexFaucher@discussions.microsoft.com> wrote:
> >
> >We are having a large problem developing a BDA driver. The source of this
> >problem is that the documentation for writing a BDA driver explains what
> >everything does, but not what actually happens in terms of successfully
> >instancing a filter that will be used by Media Center.
> >
> >This makes debugging impossible as very little of our code actually runs
> >before Media Center decides not to acknowledge our device.
>
> Correct. It is an enormous pain in the butt. Media Center is an
> absolutely dreadful environment for a driver developer. I've made two
> ventures there, and I may actually decline the next opportunity that
> presents itself.
>
> What ARE you seeing? Are you getting loaded in the capture graph at boot
> time?
>
> >Otherwise, does anyone have a method to successfully diagnose graph building
> >and filter caps problems?
>
> The first step is to make sure your driver works in a non-MCE graphedt,
> where things are more predictable. After that, make sure your MPEG2
> encoders are certified for MCE; that's another common failure.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.
>