> 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. Felix
