Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
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? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger 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. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
Klaus Schmidinger 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? Afaik DVB API does not specify any way to do that. For now, I suggest that you simply try to open the frontend. If this fails, you may assume some kind of ressource limitation... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
Manu Abraham wrote: > On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger > 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. Imho limitations or dependencies between different *adapters* are not acceptable. If a driver maps frontends to different adapters, the driver pretends that they can be used independent of each other and without limitations. If there are limitations, the frontends must be assigned to the same adapter. Anything else does not make any sense to me. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
On Wed, Jan 6, 2010 at 7:52 PM, Oliver Endriss wrote: > Manu Abraham wrote: >> On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger >> 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. > > Imho limitations or dependencies between different *adapters* are not > acceptable. If a driver maps frontends to different adapters, the driver > pretends that they can be used independent of each other and without > limitations. > > If there are limitations, the frontends must be assigned to the same > adapter. Anything else does not make any sense to me. Ok, I agree to your point. But it all depends on what we define an adapter is: Is the adapter specified by the I2C interface, or is it by the actual number of DMA interface ? In the case of the card that which is mentioned in here, a CX88 PCI card, it neither has dual I2C nor dual DMA. It is just a simple software mutex in the driver alone. But, suppose a device has lets say 13 physical DMA interfaces which can be applied to a total of 18 DMA interfaces, ie at any time the physical chip can do a total of 13 DMA instances at any given point of time. Now, all the DMA transfer for all the 'n' interfaces will be over a single memory interface, say maybe a Dual ported memory or something that way. Eventually there will exist a memory bandwidth on any physical memory. That bandwidth has to be shared between 13 instances. So in reality there will be a given limitation on the bandwidth in use, ie for example, when at any given point of instance, you might be able to do 2 SD streams, while practically it might be possible to handle only a single HD stream, or maybe a HD + SD stream, but might not be possible to handle 2 HD streams, to mention a specific case. For any device that we consider, there is a limitation on the bandwidth that each interface or whatever we might call it. But eventually, I guess maybe it is better for the driver to handle it internally, though it may look rather damned complex, with lot of multiplexing of the DMA and computation of the bandwidth in use. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
Manu Abraham wrote: > On Wed, Jan 6, 2010 at 7:52 PM, Oliver Endriss wrote: > > Manu Abraham wrote: > >> On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger > >> 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. > > > > Imho limitations or dependencies between different *adapters* are not > > acceptable. If a driver maps frontends to different adapters, the driver > > pretends that they can be used independent of each other and without > > limitations. > > > > If there are limitations, the frontends must be assigned to the same > > adapter. Anything else does not make any sense to me. > > Ok, I agree to your point. But it all depends on what we define an adapter is: I define an adapter as the entity /dev/dvb/adapterX, as seen by the application software. An application may assume that devices from adapter X do not interfere with devices from adapterY (X != Y). It does not matter, whether two adapters reside on the same hardware (PCI card, whatever), if (and only if) the driver can guarantee that they do not interfere. In this case it is the choice of the driver developer, whether he uses one or more adapters. I prefer one adapter. > Is the adapter specified by the I2C interface, or is it by the actual > number of DMA interface ? No, these are internals of the driver. User space software should not have to care about this stuff. > In the case of the card that which is mentioned in here, a CX88 PCI > card, it neither has dual I2C nor dual DMA. It is just a simple > software mutex in the driver alone. Imho this driver should better implement *one* frontend, with some kind of mode switching... > But, suppose a device has lets say 13 physical DMA interfaces which > can be applied to a total of 18 DMA interfaces, ie at any time the > physical chip can do a total of 13 DMA instances at any given point of > time. > > Now, all the DMA transfer for all the 'n' interfaces will be over a > single memory interface, say maybe a Dual ported memory or something > that way. Eventually there will exist a memory bandwidth on any > physical memory. That bandwidth has to be shared between 13 instances. > So in reality there will be a given limitation on t
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
Klaus Schmidinger 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? Shouldn't all frontends that are independent show up as completely different adapters in /dev/dvb/, so that VDR can assume only one frontend per adapter is usable simultaneously? If not, why is that? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
