[linux-dvb] Multiple frontends on a single adapter support

[linux-dvb] Multiple frontends on a single adapter support

[Christophe Thommeret]

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?

-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Andreas Oberritter]

Christophe Thommeret wrote:
> 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?
> 

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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Uri Shkolnik]

--- On Thu, 9/11/08, Andreas Oberritter <obi@linuxtv.org> wrote:

> From: Andreas Oberritter <obi@linuxtv.org>
> Subject: Re: [linux-dvb] Multiple frontends on a single adapter support
> To: 
> Cc: linux-dvb@linuxtv.org
> Date: Thursday, September 11, 2008, 6:16 PM
> Christophe Thommeret wrote:
> > 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?
> > 
> 
> 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
> 


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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Andreas Oberritter]

Uri Shkolnik wrote:
>> From: Andreas Oberritter <obi@linuxtv.org>
>> 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.
> 
> 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
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Regarding the multiproto situation:

A number of developers, maintainers and users are unhappy with the
multiproto situation, actually they've been unhappy for a considerable
amount of time. The linuxtv developer community (to some degree) is seen
as a joke and a bunch in-fighting people. Multiproto is a great
demonstration of this. [1] The multiproto project has gone too far, for
too long and no longer has any credibility in the eyes of many people.

In response, a number developers have agreed that "enough is enough" and
"it's time to take a new direction", for these developers the technical,
political and personal cost of multiproto is too high. These developers
have decided to make an announcement.

Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby
announcing that we no longer support multiproto and are forming a
smaller dedicated project group which is focusing on adding next
generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a 
different and simpler API.

Basic patches and demo code for this API is currently available here.

http://www.steventoth.net/linux/s2

Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and
namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know
we want to fix.

but ...

Is the new approach flexible? Yes, we're moving away from passing fixed
modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen
modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application 
developer wants to support the new standards - binary compatibility!

We want feedback and we want progress, we aim to achieve it.

Importantly, this project group seeks your support.

If you also feel frustrated by the multiproto situation and agree in
principle with this new approach, and the overall direction of the API
changes, then we welcome you and ask you to help us.

Growing the list of supporting names by 100%, and allowing us to publish
your name on the public mailing list, would show the non-maintainer
development community that we recognize the problem and we're taking
steps to correct the problem. We want to make LinuxTV a perfect platform
for S2, ISDB-T and other advanced modulation types, without using the
multiproto patches.

We're not asking you for technical help, although we'd like that  :) ,
we're just asking for your encouragement to move away from multiproto.

If you feel that you want to support our movement then please help us by
acking this email.

Regards - Steve, Mike, Patrick and Mauro.

Acked-by: Patrick Boettcher <pb@linuxtv.org>
Acked-by: Michael Krufky <mkrufky@linuxtv.org>
Acked-by: Steven Toth <stoth@linuxtv.org>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>

* [1]. Rather than point out the issues with multiproto here, take a
look at the patches and/or read the comments on the mailing lists.

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Steven Toth]

Hans Werner wrote:
> -------- Original-Nachricht --------
>> Datum: Wed, 10 Sep 2008 17:10:19 +0200
>> Von: Christophe Thommeret <hftom@free.fr>
>> An: Steven Toth <stoth@hauppauge.com>
>> CC: linux-dvb@linuxtv.org
>> Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support
> 
>> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
>>>> Is this card able to deliver both S and T at the same time?
>>> No, the hardware can do S/S2 or T.
>>> The driver in the S2API tree only has S/S2 enabled (for the time being).
>> So, maybe we have to think a bit about how to add support for this kind of
>> device.
> 
> Yes, absolutely, and I hope this can go in to S2API and the kernel. It would be a lie
> to claim that linux supports the HVR4000 until this is done. Fortunately Steven
> and Darron made experimental drivers which do this.
> 
>> I mean, if the driver provides different adapters/frontends (say 
>> adapter0/frontend0 and adapter1/frontend0), a typical application will see
>> these as separate devices, and then when a user watch a S channel, the app
>> assumes that the T frontend is free while in fact it's not.
>> For example, Kaffeine updates its channels list according to which
>> channels 
>> can be viewed (based on which frontends are free). So, if you are
>> recording a 
>> S channel, all channels on this freq are shown as available and all T 
>> channels are also shown as available. But in the HVR4000 case, it's false,
>> since the T tuner isn't free.
>>
>> Maybe a solution could be to have :
>> - adapter0/frontend0 -> S/S2 tuner
>> - adapter0/frontend1 -> T tuner
> 
> This is what the multifrontend (mfe) driver at http://dev.kewl.org/hauppauge does.
> And Kaffeine is the only major DVB app which correctly finds the two frontends
> and uses them correctly (well done!!). Or very nearly -- TV watching is perfect, but
> the only slight problem happens when you are recording:
> 
> (1) record a DVB-T channel:
> -->all DVB-T channels except those in same multiplex vanish from the available
> channels list (correct)
> -->no satellite channels vanish (incorrect)
> 
> (2) record a DVB-S channel;
> -->all DVB-S channels except those on the same multiplex vanish from the available
> channels list (correct)
> -->no DVB-T channels vanish (incorrect)
> 
> It's a small problem, easily fixed I would think.
> 
>> So applications could know that these 2 frontends are exclusive.
>> That would not require any API change, but would have to be a rule
>> followed by 
>> all drivers.
> 
> Yes, if we keep to that rule then only frontends which can operate truly
> simultaneously should have a different adapter number.

If everyone wants this in the S2API tree then it's pretty simple to add, 
I just didn't want to overload the tree with too much baggage that 
causes it to get stuck in the approval process.

We need an S2 API in the next few weeks, and anything that delays that 
is bad news for everyone.

I'll publish a mail about this in a separate thread, and seek feedback 
from everyone.

- Steve






_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Multiple frontends on a single adapter support. (Was: Re: DVB-S2 / Multiproto and future modulation support)

[Christophe Thommeret]

Le Wednesday 10 September 2008 20:47:03 Steven Toth, vous avez écrit :
> Hans Werner wrote:
> > -------- Original-Nachricht --------
> >
> >> Datum: Wed, 10 Sep 2008 17:10:19 +0200
> >> Von: Christophe Thommeret <hftom@free.fr>
> >> An: Steven Toth <stoth@hauppauge.com>
> >> CC: linux-dvb@linuxtv.org
> >> Betreff: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation
> >> support
> >>
> >> Le Wednesday 10 September 2008 15:38:23 Steven Toth, vous avez écrit :
> >>>> Is this card able to deliver both S and T at the same time?
> >>>
> >>> No, the hardware can do S/S2 or T.
> >>> The driver in the S2API tree only has S/S2 enabled (for the time
> >>> being).
> >>
> >> So, maybe we have to think a bit about how to add support for this kind
> >> of device.
> >
> > Yes, absolutely, and I hope this can go in to S2API and the kernel. It
> > would be a lie to claim that linux supports the HVR4000 until this is
> > done. Fortunately Steven and Darron made experimental drivers which do
> > this.
> >
> >> I mean, if the driver provides different adapters/frontends (say
> >> adapter0/frontend0 and adapter1/frontend0), a typical application will
> >> see these as separate devices, and then when a user watch a S channel,
> >> the app assumes that the T frontend is free while in fact it's not.
> >> For example, Kaffeine updates its channels list according to which
> >> channels
> >> can be viewed (based on which frontends are free). So, if you are
> >> recording a
> >> S channel, all channels on this freq are shown as available and all T
> >> channels are also shown as available. But in the HVR4000 case, it's
> >> false, since the T tuner isn't free.
> >>
> >> Maybe a solution could be to have :
> >> - adapter0/frontend0 -> S/S2 tuner
> >> - adapter0/frontend1 -> T tuner
> >
> > This is what the multifrontend (mfe) driver at
> > http://dev.kewl.org/hauppauge does. And Kaffeine is the only major DVB
> > app which correctly finds the two frontends and uses them correctly (well
> > done!!). Or very nearly -- TV watching is perfect, but the only slight
> > problem happens when you are recording:
> >
> > (1) record a DVB-T channel:
> > -->all DVB-T channels except those in same multiplex vanish from the
> > available channels list (correct)
> > -->no satellite channels vanish (incorrect)
> >
> > (2) record a DVB-S channel;
> > -->all DVB-S channels except those on the same multiplex vanish from the
> > available channels list (correct)
> > -->no DVB-T channels vanish (incorrect)
> >
> > It's a small problem, easily fixed I would think.
> >
> >> So applications could know that these 2 frontends are exclusive.
> >> That would not require any API change, but would have to be a rule
> >> followed by
> >> all drivers.
> >
> > Yes, if we keep to that rule then only frontends which can operate truly
> > simultaneously should have a different adapter number.
>
> If everyone wants this in the S2API tree then it's pretty simple to add,
> I just didn't want to overload the tree with too much baggage that
> causes it to get stuck in the approval process.
>
> We need an S2 API in the next few weeks, and anything that delays that
> is bad news for everyone.
>
> I'll publish a mail about this in a separate thread, and seek feedback
> from everyone.

Well, i guess i should have modified the subject, since it's not directly 
related to S2API.
Do not spend your time on this at that moment, S2API has the priority.

I just wanted to get feedback about this solution, since it does not involve 
any API change but only requires devs approval to follow this rule.


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Multiple frontends on a single adapter support

[Christophe Thommeret]

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?


-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Uri Shkolnik]

--- On Thu, 9/11/08, Christophe Thommeret <hftom@free.fr> wrote:

> From: Christophe Thommeret <hftom@free.fr>
> Subject: [linux-dvb] Multiple frontends on a single adapter support
> To: linux-dvb@linuxtv.org
> 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@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


      

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Multiple frontends on a single adapter support

[Steven Toth]

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

...

> 
> 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?) ?

Could it, yes. I'll go with the majority on this to be honest.

As far as I'm concerned the hvr3000 patches (if you read the patch 
description) were not to be merged as-is, they were for discussion and 
review. It's encouraging good to see that discussion happening now, 
later than expect, but good.

The inodes largely reflect API usage so it needs to be obvious, if we 
think this isn't, then we should come to a consensus and resolve for the 
future.

Obviously, the impact would be that existing applications that are using 
unofficial patches would have to be patched again, away from the current 
approach.

- Steve



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb