--- On Thu, 9/11/08, Christophe Thommeret <hftom@xxxxxxx> wrote: > From: Christophe Thommeret <hftom@xxxxxxx> > Subject: Multiple frontends on a single adapter support > To: linux-dvb@xxxxxxxxxxx > Date: Thursday, September 11, 2008, 4:35 PM > Hi all, > > ( Please don't mix this thread with the "DVB-S2 / > Multiproto and future > modulation support" thread. ) > > Summary: > > Some devices provide several tuners, even of different > types. > So called "Dual" or "Twin" tuners can > be used at the same time. > Some others (like HVR4000) can't be used at the same > time. > > My initial question was: How could an application know that > 2 (or more) tuners > are exclusive (when one is used the other(s) is(are) not > free.) > > I suggested the following: > Since actually all multiple tuners drivers expose several > fontend0 in separate > adapters, maybe a solution for exclusive tuners could be to > have : > - adapter0/frontend0 -> S/S2 tuner > - adapter0/frontend1 -> T tuner > so, an application could assume that these tuners are > exclusive. > > Janne Grunau acked the idea and said that an experimental > driver for HVR4000 > is already doing this. > > This was confirmed by Steven Toth: > "Correct, frontend1, demux1, dvr1 etc. All on the same > adapter. The > driver and multi-frontend patches manage exclusive access > to the single > internal resource." > > Andreas Oberritter said: > "This way is used on dual and quad tuner Dreambox > models." (non exclusive > tuners). > "How about dropping demux1 and dvr1 for this adapter > (exclusive tuners), since > they don't create any benefit? IMHO the number of demux > devices should always > equal the number of simultaneously usable transport stream > inputs." > > Uri Shkolnik said: > "Some of the hardware devices which using our chipset > have two tuners per > instance, and should expose 1-2 tuners with 0-2 demux (TS), > since not all DTV > standard are TS based, and when they are (TS based), it > depends when you are > using two given tuners together (diversity mode, same > content) or each one > is used separately (different frequency and modulation, > different content, > etc.)." > > > > So, here are my questions: > > @Steven Toth: > What do you think of Andreas' suggestion? Do you think > it could be done that > way for HVR4000 (and 3000?) ? > > @Uri Shkolnik: > Do you mean that non-TS based standards don't make use > of multiplexing at all? > Take CMMB for example, some standard's options are that the content is RTP based, so the content path is via the IP stack, another CMMB mode is Mpeg4 frames. DAB (and DAB-IP) are other good examples. By demux.h ( http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-kernel-v4/linux/include/linux/dvb/demux.h?view=markup ) demux is "de-multiplexing of a transport stream (TS)", since those standards are not TS based, they can not be "demuxed". If its an IP-based DTV standard, you just create a pipe from the device into the IP stack and pass all content. If it a frames based standards, you need other mechanism, anyway, you don't need a demux > > -- > Christophe Thommeret > > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
