This is exaclty what I am saying, you have to take into consideration that other BDA capture filters may be installed and how they will interact if you try to connect them to a Spectrum Tuner filter etc.

A good portion of my time as a software engineer is spent trying to get my code to interact and work with libraries etc that are designed to spec but never actually meet them, it is just the way it is.

Also you may have a non complient BDA driver installed that you know will not work with WS, how do you let WS know not to use it if WS is just using the System Enumeration to work out what cards are available.

EDIT:
Spelling fixes, my time is obviously not used to increase my spelling capacity :-)

Nate,

I am not sure if we need a glodal storage system for card info, you may want to have WS and DW use different cards etc.

The way I see it working is use the System Enumeration index to pair the Tuner and Capture filters up and have some way for the app the store and use this info, this info is not shared between apps, you need some way of telling you app what is available.

You then just create a graph with the first pair and try to run it, if it fails destroy it and build a graph with the next pair in it etc, you can also keep an internal (to the app) tally of what card is in use etc so you dont try to use an obviously in use card.

You could also add info about if the card needs a demodulator etc and store that info as well.

Again this would work until BDA drivers were added or removed effectivly breaking your pairing of the tuner/capture filters.

true. I wasn't trying to reiterate the sharing between apps thing, just the idea of how to manage filters by having "cards" which get assigned specific tuner and capture filters.

I've just been looking in graphedt and noticed the Filter Moniker shown for the THDTV DVB-t BDA Tuner Filter has

I havn't got my second card in this machine at the moment so i can't test it, but my theory is that each card will have different moniker based on it's hardware location (pci slot). Rather than relying on enumeration id's we could use this.

The moniker ID should be enough, here is mine for the Tuner



From memory there is a way of parsing and creating a moniker from the ID and binding to an object, just cant put my finger on it at the moment.

I can not put my second card my dev machine at the moment so can not test this yet.

Yup they will but how does this extend to USB devices ?

If anyone has the code to parse moniker's post it. I went looking for it a while ago but never found it.

This code is from an old project I was working on (Virtual VCR) about 2 years ago.

Sorry I was meaning code to parse the moniker into it's individual parts like the pci slot number for example

Why would you want to do that?

As for monikers, the hardware ID is a 32 bit unsigned long. If you can create a unique 32 bit number that is the same for both the tuner and capture filters on the one card, then I can use that.

nate,

No - not the way I'm thinking.

Do it in 2 parts.

Part 1
At application start-up create all of your graphs.[list]

[*]Enumerate Tuner filters.

[*]Enumerate Capture filters.

[*]For each Tuner filter from 1. create a graph and:
[list]

[*]Insert and connect Network Prover and Tuner filters

[*]For each Capture filter add it to the graph and try connecting it to the Tuner filter

[*]If you try all Capture filters for a Tuner filter and don't find a match then destroy the graph
[list]

[*]Finish assembling the remaining parts of graph

[*]Next loop back to 3.
[list]Now you'll have as many graphs as there are tuner cards sitting in stop state waiting to be used (correctly configured BDA driver cards anyway).


Part 2
Now the user wants to watch a programme or your app has a scheduled programme to record.
[list]

[*]Start with the first graph.

[*]Submit a new tune request on the Network Provder.

[*]you try to transistion to the run state to see if the card is free

[*]If you succeed then great.

[*]If you fail to transition to run state then try the next graph and go back to 2.

[*]If you can't find an available card, tell the user and wait for their action or wait for the next scheduled programme to record and try it all again.
[list]

This is just one way to do it and it may not even be the best. May I suggest trying some other newsgroups/forums out there and see if anyone else has tried this before us.

Spectrum

Version 1.5.1.0 available for developers only. test_drivers.zip

Before installing the drivers for each card, edit both .inf files and make sure the line is identical in both .inf files.

The last four digits make a ULONG for the hardware ID (0x04030201 in the example above). After installing the first card, edit both .inf files and change the hardware ID, and then install the second card.

Once again, the value must be the same in both .inf files for a single card, but must be different for each card you install.

If it works you should see it under the device parameters in regedit as in this screen cap regedit.bmp


Spectrum

This would work fine except that you might not know which decoder and renderer filters you need in the graph until the time when you want to start it. Like in DW you wouldn't know which filters would be needed until someone selected a channel, and then if they want to change to a different channel that uses different decoder then there will be no option but to temporarily stop the graph. I guess we'll just have to risk the chance of another program grabing the card during a channel change.

Mmm I guess that would be correct.

Can I suggest any interested developers sign up over at Microsoft's DirectXAV mailing list. I've been following it for a few months and it seems to have some intelligent people posting - even replies from Microsoft folk at times.

I think we're getting to the point where we need help from people who know the answers - I'm just telling you things as I see them based on what I've read so I could be misinterpreting the whole BDA architecture for all I know :? That list has a global reach so it's probably a better forum for this topic.

Spectrum

Spectrum, I think you are correct in you approch to building the graphs, the BDA sample does this:

1. Sets up the Network Provider
2. Adds a tuner filter from the system enum
3. Tries to connect each of the available Capture filters
4. When it finds a capture filter that connects that is what it uses.

I agree that is is how BDA should be used.

The only thing I have a problem with is you need to give the user/appliction the ability to chose which tuner device to use and not rely on the system enum to just try all tuners. I think the Moniker approch would be best, in a setup screen you can show the user what Tuners are available and then get them to select which ones the app can use.

You may want to build graphs with different filters (decoders, mux filters, file dump filters) etc as Nate has said. From this point of view you could build all the BDA section of the graph and have that ready, then add the filters you need and then run the graph, if the graph does not run you can remove the filters you just added and try the next one.

Alternativly you could just build the graph from scratch each time you needed it and use the next tuner from the above list you generate at setup time.

I am glad we started this as I was strugling with how to approch this multi card stuff, I now have a much better understanding and think I am almost rerady to start playing :-)

null_pointer,

You've hit the nail on the head. There is more than one approach but the overall process will still be the same to get a fully built graph.

Spectrum

Yep that would work. It would make it a bit slow if the first is in use, but the only way to speed it up would be to test if the first card is in use before adding all the extra filters, which would then slow down the more common situation of the first card being free.

Spectrum,

Any news on being able to create the hardware ID number programaticly yet?

I have made available a test build of Web Scheduler that should work with multiple BDA cards, it would be good if people could just install the drivers etc without having to edit the inf files etc.

Unfortunately no. The two drivers run independently so I haven't come up with a way for them both to communicate a single number. Other than loading a value from the registry I can't think of a way to make a value that is uniqe between hardware but common to both drivers.

Spectrum

It's a long shot but what about the card MAC number?

The MAC number is only available to the tuner driver, not the capture driver.

Spectrum

New drivers with mostly bug fixes. Version 1.5.2.0.

test_drivers.zip

Spectrum

Bugger :cry:

Ok how about this.

From what I can tell each driver is reading from the UniqueCardID key from its registry area (PCI slot based), meaing that the first Tuner and capture driver for one card read from one area of the registry and the second tuner and capture driver read form its area based on the PCI slot that each card is inserted into.

Now this ID is being created when the driver is installed using data from the INF files, what you could do is leave the registry value blank, if it does not exist then the first time something tries to read it it creates a random number and saves it into the registry UniqueCardID filed.

This would mean that the value is blank until the first item tires to read it, it would detect that the value is not available and create a randon value and set the registry for future use etc.

This would mean that you are still reading the value from the registry but it is dynamicly created the first time you try to load the driver instead of having to set it in the INF file when you install it.

Each driver has its own registry value. They would each generate a different random number. Good idea though.

Spectrum

Doh, I assumed that each PCI entry covered one pair of drivers i.e tuner and capture driver. oh well.

Is the MAC address retrievable via a std bda interface (or a non standard one for that matter)

I haven't seen a standard one, but you could use a non standard one I guess.

Spectrum

Could you implement it as an IPropertyBag element ?

Unforunately it's a little more complicated than that. It's certainly possible to do it, but why would you want the MAC number?

Check out this link http://www.wd-3.com/archive/KsProxyPlugin.htm for KsProxy plug-ins.

Spectrum

Only for licensing really. But as it's not going to be a generic property of each manufacturers cards / drivers, it's of questionable value ~

Strange Error - I can only view Channel 2!

If I choose channel 2 or 10, I get channel 2. Any other channel I get fully built graph (and the tune request shows the right frequency when I ahve a look in graphedit), but sound or picture.

If I switch back to the DTV drivers, I get all channels (with good signal quality), so the card can tune to the frequencies.

I see this with either the 1.5.0 drivers and 722 or the 1.5.0 (multi-card) drivers and 722.

Just tested with Showshifter - similar symptoms.

When scanning, Showshifter shows each frequency (e.g. 177500, 184500, 191500, and shows each one as locked, but picks up the ABC channels).

It looks like the driver is reporting that it is tuning, but failing to. This is a very old card - perhaps this has something to do with it.

I'm going to revert to the WDM drivers, tune to a different channel, and see what happens...

OK, a few minutes later - tuned to 7 using the WDM drivers, exited, switched to BDA drivers - now WS and SS show channel seven.

I could change channels with previous BDA driver versions (very early ones and 1.4.5).

Spectrum, has something changed in the way you tune now that would explain the symptoms I'm seeing - applications think that they've tuned - but the card is still tuned to the last frequency tuned when it was in WDM mode?

P.S. Anyone have a quicker way of shifter between drivers?

BJ

I posted this symptom a while ago now, I am glad someone else has seen a similar problem.

The link to my original post is here ...
http://robdvd.radfiles.net/viewtopic.php?t...1163&highlight=

Not as detailed as the previous poster, but I believe the two are related as in my case channel 44 was the last channel used with the WDM drivers.

I wonder if this somehow also releates to the rare issue where my WS captures are zero in size, yet the capture continues as normal in the program. hmm

Spectrum,

Slightly offtopic : does your BDA driver support TwinHan DVB-S and DVB-S CI cards too ?

Best regards,

Nicolas

To test this theory you could use the FULL TS capture mode in WS, this just dumps the full TS to disk, thus if the tuner is tuned to the wrong freq then you will effectivly be capturing a different channel than intended.

You can then just view the capture and see if it is the correct channel you wanted etc.

Spectrum,

I just test the latest release of the BDA drivers 1.5.2.0 and have noticed the pids aren't coming through in the right program.
I've tested this with 3 different builds of digitalwatch, the .722 default release, my own build which changes the channel using the ONID, TSID and SID, not the mapping the pids, and also a stripped down digitalwatch which is basically the same as my other build with the addition of being able to map the ac3 pid manually.
All 3 version have the same problem with these drivers. i'll do some more testing but i thnk it's the sd pid coming through for all programs.

Regards,
Josh

bionicdonkey,

You do realise that the driver just delivers the transport stream? The driver does not actually do anything to the TS apart from make it available in user land.

The only why I can see this happening is if the tuner was tuning to the wrong freq and thus the pids were different due to the fact that you were looking at the wrong TS (different station etc)

It's working fine now...there must of been a problem with th initial upgrade

Spectrum -- I know from reading some other topics here on the forum, you have said that you may get to the DVB-S BDA driver sometime in the future. Do you still have plans to do that?

It sounds like there has been a lot of success with the -T version! Nice work!

AFAIK Microsoft haven't even finished writing the BDA Architecture for DVB-C and DVB-S (or CI CAM / Cards for that matter). It's probably way too soon to worry about yet :?

I know that there are *some* objects out there specifically for DVB-S, but I haven't taken much time to look at them. Also, if you do a google search for DVB-S BDA, you'll find an article from May of 2000 where Philips actually had a DVB-S card working with the infant BDA architecture. So I think it's possible to get it to work, not necessarily with CAM cards, but at least for FTA. But it definitely would be bleeding edge....which we all love, right?

Personally I have no interest in FTA Satellite as there is very little worth watching. The drivers only support DVB-t and I don't have any intention of working on satellite or cable versions at this point in time.

Spectrum.

Spectrum,

I installed my second card into my computer tonight and was looking in the registry for some clues as to how to fix this and noticed that the UINumber DWORD seems to reflect which PCI slot the card is in.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumPCIVEN_109E&DEV_036E&SUBSYS_00011822&REV_11
3&61aaa01&0&40UINumber = 4
3&61aaa01&0&50UINumber = 5

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumPCIVEN_109E&DEV_0878&SUBSYS_00011822&REV_11
3&61aaa01&0&41UINumber = 4
3&61aaa01&0&51UINumber = 5

Could you use this instead of UniqueCardId?

If not, then how about using the LocationInformation string and checking that the PCI bus number and device number are the same?

nate, well spotted. I can get that number easily.

Test version 1.5.2.1 test_drivers.zip Obviates the need to fiddle with unique IDs in the .inf files

Spectrum

Working fine here with DW, SS playing and WS recording. Will move my seconed VP card into the same PC tomorrow.

Nice work lads.

Thanks for responding to this question. I know on a couple other threads there's been talk about open source licenses and whatnot -- any chance that the DVB-T BDA driver will become open source so that someone else might be able to fill the DVB-S and DVB-C gaps?

new drivers appear to work great

edit: I dont know if you were aware of this, but windows sees the drivers as version 1.5.3.1 not 1.5.2.1

I still have a slight problem, that being no AC3 sound, and for some reason no HD picture (could be related I guess...) but thats a DW prob