Ralph Metzler wrote: >Patrick Boettcher writes: > > Hi Marco, > > > > On Mon, 17 Oct 2005, Budde, Marco wrote: > > > Let's assume I want for write a DVB module > > > for a card containing two paths. Each path > > > has got its own tuner, which supports for > > > example two standards: DVB-T and DVB-S. > > > > As to my knowledge with the Linux DVB API 3 (which is currently used) it's > > not possible to handle devices with multiple frontends (and thus multiple > > muxes to demux) within one (software)-DVB-Adapter. > > > > To achieve I think this you have to register one DVB-Adapter for each > > frontend/mux-stream-combination in your driver. Up to 6 DVB adapter can be > > created at the same time with the current implementation. > >For a dual tuner card I implemented it both ways, using two adapters >or using one adapter with front0/1, demux0/1, etc. > >Using two adapters has the advantage that more software works with >it. Some programs do not support front1, etc. >Using one adapter for all tuners is also no problem with API 3 if all >tuners and demuxers are independent. > >But in your case there are tuners with different standards but the >same output? (Btw., who builds such tuners?) >You could still use 1 adapter and allocate 4 tuners, etc., you >just should not use front 0 and 1 or front 2 and 3 at the same time ... >That might be a problem but you would have the same with 4 adapters >where only 2 could be used at the same time. > >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. > >Ralph > > > This reflects a weakness in the API. The API should allow an application to request a specific type of tuner (frontend), and have the API detect what tuners are present and what type they are, and if they are currently in use or not (for instance, locked for exclusive use by another application). I also noticed other things about the API and libraries... (1) there should be a simple set of atomic, non-blocking primitives to perform certain operations (setting voltages, tones, sending primitive commands, detecting lock or signal strength, etc); (2) a 2nd layer of common operations that are still non-blocking, but may constitute "constructed" operations, such as sending chains of simple commands that perform lego type operations, such as switching polarization, changing switch inputs, etc. (3) a 3rd layer of blocking, asynchronous operations that use callbacks to indicate completion, such as moving a dish, change of lock/sync, etc. (4) scheduled operations such as polling, timed reads, timed-out events (waiting N-milliseconds for signal lock before reporting failure), etc. including the ability for a single client to manage multiple tuners/adapters, etc. I see, for instance, a lot of applications calling ioctl() with various enumerators to check for signal strength, BER, etc. instead of just calling: get_signal_strength(this); We might also want to abstract these operations to not embed explicit assumptions (for instance, that we're using Diseqc for all switch and LNB manipulations, or QPSK and not QAM or VSB for tuning, etc). Ideas? -Philip
