[linux-dvb] Multi Tuner Cards
philipp_subx at redfish-solutions.com
Tue Oct 18 23:01:14 CEST 2005
Felix Domke wrote:
>>Ralph Metzler wrote:
>>I also don't think the elsewhere mentioned SET_SOURCE call or API 4
>>would help much. Or is there support for multi-standard tuners or
>>for the case that 2 specific tuners cannot be used at the same time?
>>You could e.g. only allow front0/1 as source for demux0 and front2/3
>>for demux1 and otherwise return -EINVAL but then all the software
>>out there would have to "scan" all possible combinations first.
>Well, DMX_SET_SOURCE is of course only to select the demux source...
>In general, policies about "what can be combined" are very hard to
>describe in binary. For example, most hardware-filters still have
>problems filtering AV-streams to both memory and a hardware decoder
>(without doing twopass, if available). Then, often a hardware decoder
>can only be fed from demux0. Some other can filter to memory only in PES
>format (when decoding). Or this case, where only one of two (virtual)
>frontends can be used at once.
>One could either completely virtualize everything (having one powerful
>demux which can do everything, until all hardware resources are used,
>then switching to software filtering to allow arbitrary filtering,
>possibly including building PES-streams for the decoder in software etc.
>- awful), or build machine-specific stuff in the application which can
>handle this (for example, record from a second demux if first demux is
>used to decode).
>In the case of the frontends, i see the following additional possibilities:
> - Provide 4 virtual adapters(!), each to cover a specific DVB-S/-T
>combination. Every adapter would contain 2 frontends with fixed types.
>The application then should use only one of the 4 adapters, but could
>use both frontends. Would keep best compatibility, but is obvious a bad
>choice as for 3 (physical) frontends, you would need 8 adapters and so on.
Ok, and what about an adapter that has two frontends, one with is
8VSB, and another which can be 8VSB or QAM-64/256?
> - Have a module switch (or better, /proc-setting) which switches the
>tuner types, then have two frontends. Disadvantage is that you need to
>switch the type first in a non-standard way, but provided that
>application which don't know about this special situation can't use all
>of them anyway, i don't think this matters much.
> - Have a frontend extension to "switch personality". As there aren't
>much of these frontends (and to be honest, i still don't see THAT big
>advantage of building such frontends), i don't think this would make sense.
>I vote for the /proc-setting. Applications which know about it can use
>it properly, other ones can only use pre-selected fe types.
>I doubt that it's easier to teach applications that some of the
>frontends are "offline" than to implement the type-switch.
Why burden each application with the necessity to grok this
sort of limitation? Why not embed it into libraries as part of the
More information about the linux-dvb