Skip to contentSkip to conversation

Multiple frontends on a single adapter support

linux-dvb Christophe Thommeret 3 participants 4 messages Sep 11, 2008 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

Hi all,

( Please don't mix this thread with the "DVB-S2 / Multiproto and future modulation support" thread (like i did:) )

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?

Signature · 7 lines
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
#1 lore raw
Quoted 10 lines · Christophe Thommeret

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.)."

Quoted 9 lines

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?

I guess diversity mode should be transparent to the user, so such a device would register only one frontend (and thus only one demux) per set of tuners used in diversity mode.

While your statements about non-TS based standards make sense, those standards would require further work to be covered by a future API. In this special case, however, we're discussing correct usage of the current (TS based) demux API.

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#2 lore raw
Quoted 47 lines · Andreas Oberritter

From: Andreas Oberritter <[email protected]>
Subject: Re: [linux-dvb] Multiple frontends on a single adapter support To:
Cc: [email protected]
Date: Thursday, September 11, 2008, 6:16 PM

Quoted 2 lines · Christophe Thommeret

Uri Shkolnik said:
"Some of the hardware devices which using our

chipset have two tuners per

Quoted 1 line

instance, and should expose 1-2 tuners with 0-2 demux

(TS), since not all DTV

Quoted 1 line

standard are TS based, and when they are (TS based),

it depends when you are

Quoted 1 line

using two given tuners together (diversity mode, same

content) or each one

Quoted 1 line

is used separately (different frequency and

modulation, different content,

Quoted 8 lines

etc.)."

So, here are my questions:

@Steven Toth:
What do you think of Andreas' suggestion? Do you

think it could be done that

Quoted 4 lines

way for HVR4000 (and 3000?) ?

@Uri Shkolnik:
Do you mean that non-TS based standards don't make

use of multiplexing at all?

Quoted 1 line

I guess diversity mode should be transparent to the user, so such a
device would register only one frontend (and thus only one demux) per
set of tuners used in diversity mode.

While your statements about non-TS based standards make sense, those
standards would require further work to be covered by a future API. In
this special case, however, we're discussing correct usage of the
current (TS based) demux API.

Quoted 3 lines

Regards,
Andreas

Regarding the diversity mode - Need to be kept flexible, a device can switch mode (between using a given set of tuners as input for single content or use each tuner for different content)

Regarding Non-TS - I must disagree, there are several posts on this ML that contradict your assumptions, and (much) more important, CMMB after two months of service has much bigger deployment than DVB-H, DVB-T2 and DVB-S2 putting together. T-DMB (DAB) also has much bigger audience.

The optimum is to support all DTV standards :-) , but facing the reality, we must set some priority, and I think the priority should be base on the current users number, and the forecast of DTV standards "market share".

Uri

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

#3 lore raw
Quoted 9 lines · Uri Shkolnik
Quoted 8 lines

From: Andreas Oberritter <[email protected]> While your statements about non-TS based standards make sense, those
standards would require further work to be covered by a future API. In
this special case, however, we're discussing correct usage of the
current (TS based) demux API.

Quoted 3 lines

Regarding the diversity mode - Need to be kept flexible, a device can switch mode (between using a given set of tuners as input for single content or use each tuner for different content)

Regarding Non-TS - I must disagree, there are several posts on this ML that contradict your assumptions, and (much) more important, CMMB after two months of service has much bigger deployment than DVB-H, DVB-T2 and DVB-S2 putting together. T-DMB (DAB) also has much bigger audience.

Maybe my phrasing was unclear. "Future API" shall mean any API not covered by Linux 2.6 _now_. I.e. "future API" is any of S2API or multiproto or whatever extension will eventually be merged into the upstream kernel in the future.

What we are discussing here is an implementation detail for a driver using the _current_ API (unless someone thinks that the API needs to be changed to support the two tuners of the HVR4000).

Please keep your suggestions for yet unimplemented transmission methods in a seperate thread.

Regards,
Andreas

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb