<br><br>
<div><span class="gmail_quote">On 1/15/07, <b class="gmail_sendername">Ralph Metzler</b> &lt;<a href="mailto:rjkm@metzlerbros.de">rjkm@metzlerbros.de</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Klaus Schmidinger writes:<br>&gt; I&#39;m wondering how an application is supposed to handle<br>&gt; devices with multiple frontends.
<br>&gt;<br>&gt; Let&#39;s assume a device that provides<br>&gt;<br>&gt;&nbsp;&nbsp; dvb/adapter0/frontend0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DVB-S<br>&gt;&nbsp;&nbsp; dvb/adapter0/frontend1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DVB-T<br>&gt;<br>&gt; so that it can receive both DVB-S and DVB-T. Does this
<br>&gt; mean that it can simultaneously receive one DVB-S transponder<br>&gt; and one DVB-T transponder? Or can it receive either a DVB-S<br>&gt; *or* a DVB-T transponder, but not both at the same time?<br><br><br>Hmmm, good question. I only have some devices which can do
<br>simultaneous reception. But I think there are some with<br>different tuners sharing TS outputs as well.<br>Since the open is not handled by the driver itself we also cannot lock<br>the frontend accesses against each other.
</blockquote>
<div>&nbsp;</div>
<div>There are 2 different cases</div>
<div>&nbsp;</div>
<div>(1) multiple frontends sharing the same TS interface</div>
<div>(2) multiple frontends, each having it&#39;s own TS interface.</div>
<div>&nbsp;</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Maybe those should be handled like one multi-protocol frontend?<br>Not sure if Manu&#39;s multi-proto stuff would also handle this across
<br>different tuners. We would need another layer of abstraction.<br><br>Or should just the demuxes lock against each other? So, if one<br>demux has filters set, the other one will not accept any.<br>I guess the frontends themselve work at the same time, they
<br>just share the same TS input?</blockquote>
<div>&nbsp;</div>
<div>for (1), they just share the same TS interface which is already implemented, but when we have a derivative of (2)&nbsp;multiple frontends, we can have say for example 4 frontends with 2 TS interfaces or 3 TS interfaces.</div>

<div>&nbsp;</div>
<div>in this case the frontends could be handled by either of the TS interfaces, depending on how you configure it.</div>
<div>&nbsp;</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">We&#39;ll definitely need some better input handling for those new cards.<br>E.g. if you have 2 demuxes connected to 2 frontends or data from the
<br>PC, 1 or 2 decoders on the card, one or more of those new USB CAMs serving<br>one of several cards, etc.<br>I&#39;m starting to do some hacking with something like modified V4 API +<br>multi-proto frontends + other goodies ...
</blockquote>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>I was thinking in the lines of the adapter object that i worked upon earlier, adding functionality to the same such that device functionality is abstracted by the user application through the adapter object. Currently i have some small functionality like bus reset, sync word setup&nbsp;etc&nbsp;associated with the adapter object, but can be extended for others as well.
</div>
<div>&nbsp;</div></div>
<div>Another advantage of this method is that it makes the integration of hybrid devices as well into the existing framework without having workarounds.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>Manu</div>
<div><br>&nbsp;</div>