Well I'm finally taking a look into power management. As the driver stands now it's reasonably compliant - it won't stop you from changing to different power states.

The hardware supports S0 and S3 which is normal for this type of device. That means either fully on or fully off (though powering down to S3 leaves just enough power to be awakened back in to S0).

This is what I thought I'd implement:

Firstly, on powering up from S3 to S0, I'll re-submit the last tune request to get the hardware back on the previously tuned frequency. It appears a normal part of powering down is for the system to put running graphs into the stop state so streaming (DMA etc) will be stopped and later restarted outside of the driver.

Secondly I'll look at idle detection. I'm thinking 5 seconds after the graph has transitioned to stop state I'll power the device down to S3 to save power. When a graph next goes to pause or run I'll power the device back up.

I have no real idea about the electrical characteristics of the Twinhan hardware so I'm not sure how much electricity (and greenhouse gases) this will save but it can't hurt.

The completion of this part of the code will mark the end of the implementation of all the major components of the driver. After this it should just leave ongoing tweaking and maintenance.

Spectrum

I don't know whether thermal characteristics will affect the tuner etc. But I'm definitely of the opinion that leaving the h/w up, running and stable unless the system explicitly commands an S3 power state is the way to go. No way do I think the drivers should be powering down the device/s independantly

I tend to agree, the power management should be done by the OS, that way as a user at least you have some control over what is happening.

Fair enough - I'll add it when I can make it an option in the driver properties Power Management tab, but as I'm not a Windows programmer I'll have to move idle detection further down the todo list.

Spectrum

Spectrum

I do not know about other people, but once the card is tunned to something, it cause interferance to analoge TV stations esp. ABC in Melb.

Can you put it into a state were it does not cause interference if the card has not been used for a while, e.g. maybe do a power reset, or de-tune it.

Cheers
Damon.

This is hardly the fault of the card. It's crappy cabling / crappy shielding / non metallic case / overclocking harmonics / crappy power supply / etc etc etc

But why aggravate the situation by leaving it tuned into a channel when we have control of the card but not as much control over the other factors you mentioned.

I am having a problem where if I hibernate the system when it is resumed next time WS tires to start a capture sometimes the call to the get_SignalStrength funtion on the iTuner interface lockes up and never returns.

Once the function is locked I can not stop WS or kill off java.exe, I have to reboot the machine.

Well this problem is still occurring, I am going to have to move back to VP SDK development until this problem is sorted out.

I have created a new CaptureEngine.dll that uses the old VP SDK thsource.ax filter and the old (original drivers) this was working for me before so I will move back to using that, it is a pitty as the BDA driver is very good at the moment but I can not have my DVR machine locking up randomly it is not acceptable.

null,

The issue u decribe i think is similar to my 100% CPU. java.exe cannot be killed off completely.

I have had this happen testing 2.9 beta, though was not 100% cpu, the web interfaceds till worked but a capture kept going (ie file was growing), killing java.exe stoppedt the capture/file growth, BUT java.exe still was runing.

About 2-3min later the system just rebooted on its own (ie like reset switch reboot).

BUT the SDK version cannot do multiple cards? Is that correct? Well i guess certainly not muliple "other" BDA cards (ie AverT, Dvico(soon mabye) etc)?

Yes the new SDK version is single card only.

Yep, there is still something screwy with the BDA driver, it is ok most of the time but I can not make it reliable on my DVR machine so am having to switch back to development of the SDK version.

nooooooooooooooooo! ok i understand.

I still feel given it seems maybe in "weeks" there will be two "factory" BDA cards with "real" (ie VStream) BDA drivers available (ie currently the AverT and soon the Dvico) that "standard" BDA support is a better option.......... as a VP owner i don't see it as 'neglecting' VP users, the VP BDA drivers do work....be it with pretty minor issues.....the latest Spectrum drivers and non BDA have not missed a beat on my system since release. I don't use powerup for capture but.... my PC turns on/off using BIOS timer and "switch off" each day. it seems the reliability is lost more in using this feature.
(i for one would have no issues purchasing say an Aver card for WS use if BDA drivers could not be sorted, they are pretty cheap cards now)

Also of note Nate has stated he is going the way of standarised BDA support......so we could see a "flip side" in that WS was first to work with BDA but one need SDK for DW.....could be reversed?

Don't get me wrong, i applaude your's, specturms, nates efforts, just with the "seemless" multicard BDA.....and DW to support also in time was looking super.........

wondering, given this "new" SDK version still uses the thsource.ax filter....does that mean we get glitchy ABC capture again? (and HD for that mater....not that HD worries me)

Perhaps......with this split in development......or more of a detour.... is it possibly to somewhat keep HTTP interface/feature additions "upgradeable" with the current BDA, or is that make things mess? (sorry i got no idea). What i mean is like say additiona search features are added for the EPG search scheduling (ie capture piority or simlar) could this still be added to the BDA?(which i'd say i'll probably be used due to mulitcard)

Don't take any of the above the wrong way......last thing i want to do is tell you how to develop your software:)

D

The problem with ABC capture was due to the demuxing the thsource.ax filter was doing internally, this new version uses the same process of demuxing using the MS demuxer and file dump filters etc so the ABC problem should no happen.

Basicly I am using the Transport stream output of the thsource.ax filter and feeding it into the demuxer etc (or in the case of full ts cap straight into the dump filter) so the difference between the BDA version and the new SDK version is not that large.



I am not stopping development on the BDA version I am just working on a new SDK version for now. I agree that the future is BDA and if I have to I will purchase a new card with BDA drivers (the DIVCO perhaps) so I can use it in my DVR PC. I would love to use the Spectrum BDA driver in my DVR PC but in the last 3 days it has locked up 4 times so this is just not usable at the moment.

I doubt that VStream will have standard BDA drivers any time soon. It was requested at least 3 months ago And their response was not favourable.

I currently have a vstream device and with the custom COM object tuning hack it does work with WS.

It is disapointing that Kworld have gone to all the trouble of producing BDA drivers and then not following through and finishing them off.

Just to let people know I have had the 100% Java process problem with Driver 1.5.3.3 and WS 2.8.9.1, Have upgraded to WS 2.9.0.6/4.5.0.2.

If Java hits it's user defined max memory limit it may spend a lot of CPU time trying to seach for free memory.