On 06.01.2010 15:30, Manu Abraham wrote:
On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 06.01.2010 14:22, Tomasz Bubel wrote:
[...]
- Added support for DVB cards with multiple fontends. Note that this only
works for DVB cards where each frontend can be used independently of all the others on the same adapter.
[...] Any chance of using using DVB-T frontend on HVR-4000? This card have 2 separate frontends. And as quoted on http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000:
"Multiple frontends are supported: DVB-S/S2 and DVB-T appear as /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 respectively.
Due to a hardware limitation, the two frontends cannot be used simultaneously. However they can be used sequentially within the same application. The driver handles the mutual exclusion appropriately."
Well, that's still a problem. Is there a defined way (via the LinuxDVB driver API) through which VDR can find out whether the frontends can be used independently?
Some more food for thought ..
There is also one more added problem: Say there are two adapters and two frontends. I will try to convey the thought as simplest as possible by me...
A case in which frontend0 is bound to adapter0 and frontend1 is bound to adapter 1
This would seem like a classical case of having 2 independent adapters. But let's analyze it a bit more deeply. The two adapters A0 and A1 are on the same physical A (adapter) chip and can send you data simultaneously on both the devices. Likewise F0 and F1 can be on the same physical F (frontend) chip and can send you simultaneous data to both A0 and A1.
Now suppose that you are having F0 and F1 operational: The F chip would have a limitation on some parameter, which is based on a combination of F0 and F1. If the sum parameter is exceeded on the whole F chip, the entire F chip would crash and might need a Reset.
Likewise the same holds good for the A chip too ..
Another case is where you have A0, A1 and F0, F1 on the same chip while additionally providing F2 and F3 on virtual A0' and A1'.
But in all cases, the question remains the same. How would the application like to handle a situation, when a certain parameter will be exceed on the next operation on the next 'Fx' interface ? (If the application feels free and does the operation which might cause some parameter to exceed, the chip as a whole would not respond, unless reset again)
Operations like this might be common on cards having dual, quad and hex frontends. The card itself might be able to stream dual, quad and hex simultaneous streams.
From an application's point of view I would distinguish these cases:
1.) An adapter provides one or more frontends that can be used independently. VDR creates one cDvbDevice for each of them and uses them as completely independent devices (this is currently implemented)
2.) An adapter provides several frontends, only one of which can be used at any given time. VDR creates one cDvbDevice for the adapter and needs to handle the selection of the actual frontend inside that device. In order to implement this, we need a way of finding out this situation through the driver API.
Anything else is probably way too complex to handle and might be called "broken by design".
Klaus