Hi list,
I'm working on support for handling multiple frontends and their data
inputs on DVB-USB devices. Therefore I had to change the dvb-usb-framework
in order to register additional dvb-device-nodes and to handle an usb
device with several input streams. If everything works out well, I can
release this change just before those devices hit the market.
I know that some of the following issues have been discussed recently, but
I'm not sure on which way we agreed on :).
The device has 2 (independent) DVB-T frontends connected to one
USB-device-controller handling their (partial) MPEG2-TS data inputs.
Demuxing has to be done in software.
For me as a newbie to multiple-input-cards it seems to be the "correct
way" to register 2 frontends and 2 demuxs for one dvb-adapter.
This is how it currently looks like:
$ ls /dev/dvb/adapter0/
demux0 demux1 dvr0 dvr1 frontend0 frontend1 net0 net1
It is working well with tzap and mplayer (playing dvr0 and dvr1) under the
assumption that dvr0 is connected to frontend0 and dvr1 to frontend1.
As Ralph pointed out, there are applications out there, which are not
working with dvrX and demuxX (X >= 1). So in that case it's maybe better
to register a dvb_adapter per stream-input to be more compatible with
applications.
OTOH and IMHO, it would be better to extend the applications to make use
of all the features of the DVB-API.
In the latter case the question remains, whether the assumption that all
dvb/*0-nodes and all dvb/*1-node descibe one input stream good enough or
not. Afaik it's not a good assumption. I hope I'm wrong. :)
What is "the correct way" to mount all *0 and all *1 logically together?
thanks for your help in advance,
Patrick.
--
Mail: patrick.boettcher at desy.de
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/