[linux-dvb] Multi Tuner Cards
tmbinc at elitedvb.net
Tue Oct 18 12:06:11 CEST 2005
> 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.
- 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.
More information about the linux-dvb