Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi all,

>>>  * "The current API doesn't allow you to tune into -S2 transponders."
>> We have solved this one already, drivers also exists, people watch S2

According to the DVB-S2 specification, there can be multiple logical TS's 
within a single TS alone.

>From the specification and the STB0899 specifications all point in the 
same direction:

ISI/MIS allow multiple logical transport streams to be encoded in a single
physical transport stream.

I had asked consulted about this with the relevant people at STM, since 
i had been curious about this on the STB0899. 

What the information i received was like this: Currently, as we speak, we 
don't have TS over TS encapsulation, but there are quite some efforts 
to do this.

In this light, my question is that whether we should handle this feature 
in the infrastructure.

Manu

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

Re: [linux-dvb] DVB API update

[Andrea Venturi]

Manu Abraham wrote:
> Hi,
> 
> Simon Hailstone wrote:
>> Hi All,
>>
>> If it sheds any light on the nature of DVB-ASI, there are Linux drivers
>> available ( with source ) for the DekTec ASI adapters here :
>>
>> http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip
>>
> 
> If someone has the hardware, we can take a go at it.

hi,

here in Cineca, we are running an open source project called JustDvb-It,
it's a DVB DSMCC carousel server for interactive television, you could
grab it here:

   http://www.cineca.tv/labs/mhplab/JustDVb-It%202.0.html

as we need to interface broadcaster stuff like multiplexer (with DVB ASI
interfaces), we use plenty of these Dektec card like DTA140 and so on..

but for that purpose we found sufficient the driver provided by Dektec.

it's a simple character device with some IOCTL..

it should be not a tough task to implement a simple LinuxDvb driver, at
least for the inbound card (but there's an outgoing path too..),

but is this feature valuable? the best usage i can think of, is the
dvbsnoop utility for analysis purposes..

anyway i surely can test this driver, if it will spring out!

bye

andrea venturi



> 
> Regards,
> Manu
> 
>> Best Regards,
>> Simon Hailstone
>>
>> On 16/09/2007, *Wolfgang Wegner* < [EMAIL PROTECTED]
>> > wrote:
>>
>> Hi Manu,
>>
>> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
>> > Please don't remove the CC's. The CC'd people generally don't bother
>> > about mails from the ML, probably.
>>
>> sorry, it was definitely not my intention and I hope to include
>> all previous CC here.
>>
>> [have to read about the multiproto changes myself...]
>>
>> > Can you please point me to some ASI specs if you don't mind ?  I was
>> > once supposed to work on such a device, but then that company
>> itself got
>> > scrapped, hence never had to figure out on ASI.
>>
>> Well, AFAIK the ASI specification is not open, so I unfortunately I
>> can not point to it.
>> To be honest, the only thing about ASI comes from a fronted we use at
>> the company in professional equipment, so I am not sure if the things
>> I can tell from there are really valid for all ASI equipment. However,
>> as from time to time questions come up concerning DekTec and other
>> boards,
>> at least some basic support for ASI seems to be desirable.
>>
>> So, coming to the facts, our ASI frontend gives these as "statistics":
>> - BER
>> - sync status
>> - 204 or 188 byte/packet mode
>>
>> [...]
>> > Since it is an IOCTL call straight away within the V3 API, i would
>> like
>> > to push this into the frontend thread where it is submitted as a job
>> > kind of thing, where the userapplication can be notified in what
>> > timeframe, or via GET_EVENTS, final details can be left out for
>> the last
>> > stage.
>>
>> This sounds very reasonable for me. I have no idea yet how this frontend
>> thread is handled now, but after all all necessary information
>> should be
>> present there (e.g. lock state, to do a proper reset of averaging etc.).
>>
>> > Scale for BER is one thing that is still open ended, which i am off
>> > hook. I need to still check on this, but if you have some ideas
>> would be
>> > nice.
>>
>> Hmm... I am not sure what is needed by others, so my voice should not
>> be given too much weight here. We always use 10^-8 as the base, but for
>> some equipment this might already be too rough. On the other hand, IIRC
>> some demodulators do not return more accurate values anyways.
>>
>> > Signal Strength & SNR:
>> >
>> > In reality we can provide 2 ways for the same,
>> > 1) Relative scale
>> > 2) a scale in a decibels
>> >
>> > Even with Reverse Engineered drivers we can do 1) but for 2) we might
>> > need more info. The user could probably select what he needs using an
>> > IOCTL, relative or an absolute scale. For the relative one we can
>> just
>> > define a floor and ceiling and a relative value is extracted out.
>>
>> That is what I was thinking of, for most applications this would be
>> sufficient. I do not know what is the better solution here. Following
>> your proposal of two different styles of return values makes life easier
>> for the application (which could request the "scale" type and just take
>> this value). Even knowing the exact decibel value would make it
>> necessary
>> to interpret it differently for different transmission schemes, i.e.
>> 8 dB
>> SNR in DVB-S is no problem while there would be no reception in DVB-C...
>> On the other hand it might be confusing to get different values for the
>> same thing, which I treat as an argument for my proposal of always (if
>> possible) returning the dB value and giving the application (and user)
>> the demod min and max v

Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi,

Simon Hailstone wrote:
> Hi All,
> 
> If it sheds any light on the nature of DVB-ASI, there are Linux drivers
> available ( with source ) for the DekTec ASI adapters here :
> 
> http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip
> 

If someone has the hardware, we can take a go at it.

Regards,
Manu

> Best Regards,
> Simon Hailstone
> 
> On 16/09/2007, *Wolfgang Wegner* < [EMAIL PROTECTED]
> > wrote:
> 
> Hi Manu,
> 
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
> > Please don't remove the CC's. The CC'd people generally don't bother
> > about mails from the ML, probably.
> 
> sorry, it was definitely not my intention and I hope to include
> all previous CC here.
> 
> [have to read about the multiproto changes myself...]
> 
> > Can you please point me to some ASI specs if you don't mind ?  I was
> > once supposed to work on such a device, but then that company
> itself got
> > scrapped, hence never had to figure out on ASI.
> 
> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other
> boards,
> at least some basic support for ASI seems to be desirable.
> 
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode
> 
> [...]
> > Since it is an IOCTL call straight away within the V3 API, i would
> like
> > to push this into the frontend thread where it is submitted as a job
> > kind of thing, where the userapplication can be notified in what
> > timeframe, or via GET_EVENTS, final details can be left out for
> the last
> > stage.
> 
> This sounds very reasonable for me. I have no idea yet how this frontend
> thread is handled now, but after all all necessary information
> should be
> present there (e.g. lock state, to do a proper reset of averaging etc.).
> 
> > Scale for BER is one thing that is still open ended, which i am off
> > hook. I need to still check on this, but if you have some ideas
> would be
> > nice.
> 
> Hmm... I am not sure what is needed by others, so my voice should not
> be given too much weight here. We always use 10^-8 as the base, but for
> some equipment this might already be too rough. On the other hand, IIRC
> some demodulators do not return more accurate values anyways.
> 
> > Signal Strength & SNR:
> >
> > In reality we can provide 2 ways for the same,
> > 1) Relative scale
> > 2) a scale in a decibels
> >
> > Even with Reverse Engineered drivers we can do 1) but for 2) we might
> > need more info. The user could probably select what he needs using an
> > IOCTL, relative or an absolute scale. For the relative one we can
> just
> > define a floor and ceiling and a relative value is extracted out.
> 
> That is what I was thinking of, for most applications this would be
> sufficient. I do not know what is the better solution here. Following
> your proposal of two different styles of return values makes life easier
> for the application (which could request the "scale" type and just take
> this value). Even knowing the exact decibel value would make it
> necessary
> to interpret it differently for different transmission schemes, i.e.
> 8 dB
> SNR in DVB-S is no problem while there would be no reception in DVB-C...
> On the other hand it might be confusing to get different values for the
> same thing, which I treat as an argument for my proposal of always (if
> possible) returning the dB value and giving the application (and user)
> the demod min and max values for drawing a nice percentage scale.
> 
> For a few demods I could provide the dB calculation (namely STV0299,
> STV0288, TDA10046, TDA1002x), but probably these are those with
> fewest problems anyways.
> For others (e.g. STV0297) there seems to be no calculation possible,
> I know of other implementations using a look-up-table. If needed, I
> could do some measurements and see if we manage to get good results
> with a look-up-table, too.
> 
> > know anything. In some cases people would like to get the absolute
> value
> > for some instrumentation reasons.
> 
> It makes comparison of different frontends/setups easier, too. At least
> in some forums people try to compare their dish and stuff with this, so
> not only addicts like us might want to see these values. ;-)
> 
> [Sorry for deleting your most interesting part about silicon tuners -
> I have not had my 

Re: [linux-dvb] DVB API update

[Simon Hailstone]

Hi All,

If it sheds any light on the nature of DVB-ASI, there are Linux drivers
available ( with source ) for the DekTec ASI adapters here :

http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip

Best Regards,
Simon Hailstone

On 16/09/2007, Wolfgang Wegner <[EMAIL PROTECTED]> wrote:
>
> Hi Manu,
>
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
> > Please don't remove the CC's. The CC'd people generally don't bother
> > about mails from the ML, probably.
>
> sorry, it was definitely not my intention and I hope to include
> all previous CC here.
>
> [have to read about the multiproto changes myself...]
>
> > Can you please point me to some ASI specs if you don't mind ?  I was
> > once supposed to work on such a device, but then that company itself got
> > scrapped, hence never had to figure out on ASI.
>
> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other boards,
> at least some basic support for ASI seems to be desirable.
>
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode
>
> [...]
> > Since it is an IOCTL call straight away within the V3 API, i would like
> > to push this into the frontend thread where it is submitted as a job
> > kind of thing, where the userapplication can be notified in what
> > timeframe, or via GET_EVENTS, final details can be left out for the last
> > stage.
>
> This sounds very reasonable for me. I have no idea yet how this frontend
> thread is handled now, but after all all necessary information should be
> present there (e.g. lock state, to do a proper reset of averaging etc.).
>
> > Scale for BER is one thing that is still open ended, which i am off
> > hook. I need to still check on this, but if you have some ideas would be
> > nice.
>
> Hmm... I am not sure what is needed by others, so my voice should not
> be given too much weight here. We always use 10^-8 as the base, but for
> some equipment this might already be too rough. On the other hand, IIRC
> some demodulators do not return more accurate values anyways.
>
> > Signal Strength & SNR:
> >
> > In reality we can provide 2 ways for the same,
> > 1) Relative scale
> > 2) a scale in a decibels
> >
> > Even with Reverse Engineered drivers we can do 1) but for 2) we might
> > need more info. The user could probably select what he needs using an
> > IOCTL, relative or an absolute scale. For the relative one we can just
> > define a floor and ceiling and a relative value is extracted out.
>
> That is what I was thinking of, for most applications this would be
> sufficient. I do not know what is the better solution here. Following
> your proposal of two different styles of return values makes life easier
> for the application (which could request the "scale" type and just take
> this value). Even knowing the exact decibel value would make it necessary
> to interpret it differently for different transmission schemes, i.e. 8 dB
> SNR in DVB-S is no problem while there would be no reception in DVB-C...
> On the other hand it might be confusing to get different values for the
> same thing, which I treat as an argument for my proposal of always (if
> possible) returning the dB value and giving the application (and user)
> the demod min and max values for drawing a nice percentage scale.
>
> For a few demods I could provide the dB calculation (namely STV0299,
> STV0288, TDA10046, TDA1002x), but probably these are those with
> fewest problems anyways.
> For others (e.g. STV0297) there seems to be no calculation possible,
> I know of other implementations using a look-up-table. If needed, I
> could do some measurements and see if we manage to get good results
> with a look-up-table, too.
>
> > know anything. In some cases people would like to get the absolute value
> > for some instrumentation reasons.
>
> It makes comparison of different frontends/setups easier, too. At least
> in some forums people try to compare their dish and stuff with this, so
> not only addicts like us might want to see these values. ;-)
>
> [Sorry for deleting your most interesting part about silicon tuners -
> I have not had my hands on one yet, so cannot comment]
>
> > > I understand floating-point is not possible in the kernel, but what
> > > other possibilities are there to get rid of the device-dependent snr
> > > calculation in the application? Please, no debate about complete
> user-space
> > > driver here! I really hope there are other solutions, but I have no
> idea
> > > what is possible.
> >
> >
> > Currently we have a log10 implementation in dvb-core in dvb-math.c We
> > can use this for the same, but we will still need some

Re: [linux-dvb] DVB API update

[rjkm]

> " In 1998 the Technotrend GmbH develops the still very popular PC DVB
> card with a full-
> featured STB processor on it. In 1999 Siemens produces a card based on
> the Technotrend
> design"
> 
> However, Manu recounts, and other things that I have seen written
> collaborate with his recollection, that it was Siemens who were the
> original FF card designer.  Apparently, although it was the TechnoTrend
> produced model that stepped into the spotlight (read: became very
> popular), the TT card itself was based upon the Siemens design, and,
> hence, it was the Siemens that truly was "the mother of all FF cards".  
> If I'm not mistaken SNI (Siemens Nixdorf Informationssysteme AG; the
> actual Siemens division responsible for the card) continued to produce
> their own model through 1999, until at which time SNI was split from its
> parent company and parts of which (SNI) were used to form the
> Fujitsui-Siemens joint venture.

AFAIR, this is correct. 
I also remember that the firmware was first done by Siemens.
Technotrend added their own stuff but e.g. did not give back the
DiSEqC code to Siemens. So, the code we got from Siemens did not
include this and we had to add our own code for this.


> I also have a couple of questions related to the continuing part of the
> same above statement:
> 
> "In 1999 Siemens produces a card  and supports the development of
> the ___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB API update

[CityK]

Michael Hunold wrote:
> Hello all,
>
> before taking part of this discussion, please make sure to have read the
> v4 wiki page:
>
> http://www.linuxtv.org/wiki/index.php/Linux_DVB_API_Version_4
>
> In particular, please read the most recent Linux DVB API v4 documentation:
>
> http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf
>
> Please pay attention especially to chapter 1 "Introduction" and to the
> development history.

Hi Michael,

Manu and I had brief dialogue, not so long ago, that I've been meaning
to bring to light, and your post presents the perfect opportunity ... my
apologies for not getting back to it sooner.  Anyway, here goes:

In regards to the development history outlined within CH1 (S1.3) of the
Linux DVB API  V4 documentation, there appears to be a small error of
fact.   You have written that:

" In 1998 the Technotrend GmbH develops the still very popular PC DVB
card with a full-
featured STB processor on it. In 1999 Siemens produces a card based on
the Technotrend
design"

However, Manu recounts, and other things that I have seen written
collaborate with his recollection, that it was Siemens who were the
original FF card designer.  Apparently, although it was the TechnoTrend
produced model that stepped into the spotlight (read: became very
popular), the TT card itself was based upon the Siemens design, and,
hence, it was the Siemens that truly was "the mother of all FF cards".  
If I'm not mistaken SNI (Siemens Nixdorf Informationssysteme AG; the
actual Siemens division responsible for the card) continued to produce
their own model through 1999, until at which time SNI was split from its
parent company and parts of which (SNI) were used to form the
Fujitsui-Siemens joint venture.


I also have a couple of questions related to the continuing part of the
same above statement:

"In 1999 Siemens produces a card  and supports the development of
the first Linux driver as a diploma thesis".

Q1 - Did Siemens financially or otherwise (ie. supplying documentation
or other intellectual knowledge) support/sponsor the development of the
first Linux DVB driver?   Or am I misinterpreting the above ... perhaps
what was meant to be implied by the statement was more simply that:  it
was the Siemens card upon which the first Linux DVB driver was based ?

Q2 - For whom was this driver development the basis of a diploma thesis? 

I don't think it was for Ralph's PhD  ?  As far as Manu could recall,
and find, Ralph had already completed has dissertation and earned his
doctorate (Aug 99) prior to engagement with Convergence (Oct 99). 
Additionally, in the Metzler brothers' Linux DVB API  V3 documentation,
Ch 1 (S1.2), they only write:

"The first API for DVB cards we used at Convergence in late 1999 was an
extension
of the Video4Linux API which was primarily developed for frame grabber
cards. As
such it was not really well suited to be used for DVB cards ...

In early 2000, we were approached by Nokia with a proposal for a new
standard
Linux DVB API. As a commitment to the development of terminals based on open
standards, Nokia and Convergence made it available to all Linux
developers and pub-
lished it on http://www.linuxtv.org/ in September 2000. "

Perhaps the first DVB driver (developed prior to the Linux DVB API V1)
was used by Marcus for some diploma ?

Interesting enough, Holger recorded, in his submission to the wiki's
"DVB API history and future" article (see the original Sept 27, 2004
submission here:
http://www.linuxtv.org/wiki/index.php?title=DVB_API_history_and_future&oldid=1239
) that the Noika sponsored  Linux DVB API V1 was implemented by the
Metzlers along with Christian Theiss.

By chance, did Christian's surname "Theiss" get confused somewhere along
the way with thesis ?















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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

I cannot resist ;-)

since I stumbled over the RCU documentation I seriously would like to
invite several linuxtv people (especially Steven Stoth, Mauro Chehab,
Michael Krufky, Manu Abraham last but not least myself [but I read
already it] ;-) to read about RCU...

"RCU is a synchronization mechanism that was added to the Linux kernel
during the 2.5 development effort that is optimized for read-mostly
situations. Although RCU is actually quite simple once you understand
it, getting there can sometimes be a challenge. Part of the problem is
that most of the past descriptions of RCU have been written with the
mistaken assumption that there is "one true way" to describe RCU.
Instead, the experience has been that different people must take
different paths to arrive at an understanding of RCU. This document
provides several different paths, as follows"

http://www.rdrop.com/users/paulmck/RCU/whatisRCU.html

these few lines exactly cover a similar situation (but probably worse)
about linuxtv which covers analogue and digital TV.

Markus

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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/20/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> >
> >> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> >>
> >>> Mauro Carvalho Chehab wrote:
> >>>
>  Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> 
> > Mauro Carvalho Chehab wrote:
> >
> >> I'm just interested on see things moving forward. Please stop with
> >>
> >> your
> >>
> >> flame wars. If you are not interested on serious discussions, you
> >> shouldn't have started the thread.
> >>
> > (bla, bla, bla)
> >
>  If you can't technically argue about DVB API, but just want to play
>  politics, you don't deserve any attention on that thread.
> 
> 
> 
> >>> Missing context:
> >>>
> >>> You don't have to try for that. See the userspace thread as well, where
> >>> you were misappropriating credits. So my case was not an isolated case.
> >>>
> >>>
> >> My, my,
> >>
> >> you and Markus would have exactly _nothing_ without the prior work done
> >> by others.
> >>
> >> If you don't feel referenced enough by some lines from you currently,
> >> likely only by running on NDAs first, just make it clear and you get
> >> _your_ credit!
> >>
> >>
> >
> > there should be another thread called "Ongoing internal flamewars"
> >
> > and the first line of that mail should be idiots who cannot work together
> > and disagree whenever it's possible.
> >
> >
>
> I completely agree.
>
> It's much easier to burn the barn down than to rebuild it, and we have a
> lot of arsonists in linuxtv.
>

I don't think that there are any arsonists .. I think it's better for
all parties
to go their own way now since there's no agreement and the communication
is still on a bad level between certain people. This will at least keep
everything calm.
A bit competition shouldn't hurt after all...

As someone pointed out earlier if someone disagrees with something try
to build your own way around it to not cross each other's way.
It might not always be the best way but it keeps projects running since it's
only about drivers only support for various devices count.
As for projects which are not included in the kernel and for people who
do not get along with Mauro, the code can be submitted to the LKML
and Andrew, Greg, Linus or someone else can also pick up the sourcecode.

> People need to get over previous flame wars and get back to doing the
> one thing that brought them into the linuxtv community in the first
> place, community development.
>

It always requires 2 and more people .. I don't think that someone will
start a flamewar if there wouldn't be so many disagreements. Although
it's not worth to send flame mails around in the end..

> Anything else is a waste of everyones time and only demonstrates to the
> rest of the world how fragmented many of the linuxtv devs really are.
>

maybe it's best to keep it more fragmented for a few years... a few people
might stop their participation and newer people might join .. the only
advice I'd give here is to accept what newer people do. Nobody here is
perfect and some suggestions can be kept as suggestions without forcing
them over someone if there's no serious technical reason about it...
if people are willing to do something let them do..

> Everyone should draw their mental line under their own personal hangups
> and move on.
>

definitelly yes.

Markus

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

Re: [linux-dvb] DVB API update

[Steven Toth]

Markus Rechberger wrote:
> On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
>   
>> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
>> 
>>> Mauro Carvalho Chehab wrote:
>>>   
 Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
 
> Mauro Carvalho Chehab wrote:
>   
>> I'm just interested on see things moving forward. Please stop with
>> 
>> your
>> 
>> flame wars. If you are not interested on serious discussions, you
>> shouldn't have started the thread.
>> 
> (bla, bla, bla)
>   
 If you can't technically argue about DVB API, but just want to play
 politics, you don't deserve any attention on that thread.


 
>>> Missing context:
>>>
>>> You don't have to try for that. See the userspace thread as well, where
>>> you were misappropriating credits. So my case was not an isolated case.
>>>
>>>   
>> My, my,
>>
>> you and Markus would have exactly _nothing_ without the prior work done
>> by others.
>>
>> If you don't feel referenced enough by some lines from you currently,
>> likely only by running on NDAs first, just make it clear and you get
>> _your_ credit!
>>
>> 
>
> there should be another thread called "Ongoing internal flamewars"
>
> and the first line of that mail should be idiots who cannot work together
> and disagree whenever it's possible.
>
>   

I completely agree.

It's much easier to burn the barn down than to rebuild it, and we have a 
lot of arsonists in linuxtv.

People need to get over previous flame wars and get back to doing the 
one thing that brought them into the linuxtv community in the first 
place, community development.

Anything else is a waste of everyones time and only demonstrates to the 
rest of the world how fragmented many of the linuxtv devs really are.

Everyone should draw their mental line under their own personal hangups 
and move on.

- Steve









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

Re: [linux-dvb] DVB API update

[hermann pitton]

Am Mittwoch, den 19.09.2007, 10:24 +0200 schrieb Markus Rechberger:
> On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> > Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> > > Mauro Carvalho Chehab wrote:
> > > > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> > > >> Mauro Carvalho Chehab wrote:
> > > >
> > > >>> I'm just interested on see things moving forward. Please stop with
> > your
> > > >>> flame wars. If you are not interested on serious discussions, you
> > > >>> shouldn't have started the thread.
> > > >> (bla, bla, bla)
> > > >
> > > > If you can't technically argue about DVB API, but just want to play
> > > > politics, you don't deserve any attention on that thread.
> > > >
> > > >
> > >
> > > Missing context:
> > >
> > > You don't have to try for that. See the userspace thread as well, where
> > > you were misappropriating credits. So my case was not an isolated case.
> > >
> >
> > My, my,
> >
> > you and Markus would have exactly _nothing_ without the prior work done
> > by others.
> >
> > If you don't feel referenced enough by some lines from you currently,
> > likely only by running on NDAs first, just make it clear and you get
> > _your_ credit!
> >
> 
> there should be another thread called "Ongoing internal flamewars"
> 
> and the first line of that mail should be idiots who cannot work together
> and disagree whenever it's possible.
> 
> Markus

If it would be such simple, it would be still reasonable.

Unfortunately Manu behaves much worse behind the lines on private notes
he is sending around. When you try to calm him down, and don't agree
with him, he becomes really dirty. I don't know to what extend  he does
it ...

If there is anything left with code not fairly honored, just point to
it, that Mauro can get it in the desired shape.

For all my experience, he will always try do that.

Hermann







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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/19/07, hermann pitton <[EMAIL PROTECTED]> wrote:
> Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> > Mauro Carvalho Chehab wrote:
> > > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> > >> Mauro Carvalho Chehab wrote:
> > >
> > >>> I'm just interested on see things moving forward. Please stop with
> your
> > >>> flame wars. If you are not interested on serious discussions, you
> > >>> shouldn't have started the thread.
> > >> (bla, bla, bla)
> > >
> > > If you can't technically argue about DVB API, but just want to play
> > > politics, you don't deserve any attention on that thread.
> > >
> > >
> >
> > Missing context:
> >
> > You don't have to try for that. See the userspace thread as well, where
> > you were misappropriating credits. So my case was not an isolated case.
> >
>
> My, my,
>
> you and Markus would have exactly _nothing_ without the prior work done
> by others.
>
> If you don't feel referenced enough by some lines from you currently,
> likely only by running on NDAs first, just make it clear and you get
> _your_ credit!
>

there should be another thread called "Ongoing internal flamewars"

and the first line of that mail should be idiots who cannot work together
and disagree whenever it's possible.

Markus

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

Re: [linux-dvb] DVB API update

[hermann pitton]

Am Dienstag, den 18.09.2007, 19:07 +0400 schrieb Manu Abraham:
> Mauro Carvalho Chehab wrote:
> > Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> >> Mauro Carvalho Chehab wrote:
> > 
> >>> I'm just interested on see things moving forward. Please stop with your
> >>> flame wars. If you are not interested on serious discussions, you
> >>> shouldn't have started the thread.
> >> (bla, bla, bla)
> > 
> > If you can't technically argue about DVB API, but just want to play
> > politics, you don't deserve any attention on that thread.
> > 
> > 
> 
> Missing context:
> 
> You don't have to try for that. See the userspace thread as well, where
> you were misappropriating credits. So my case was not an isolated case.
> 

My, my,

you and Markus would have exactly _nothing_ without the prior work done
by others.

If you don't feel referenced enough by some lines from you currently,
likely only by running on NDAs first, just make it clear and you get
_your_ credit!

Hermann



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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Felix Domke wrote:
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to the end applications?
>> It is a nice idea, yes.
>> Two things, looking at
>> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> dvbfe_set imposes a certain programming scheme (because it sleeps). This
>  is a total no-go for a generic library. I don't want a library telling
> me that I have to use threads (instead of poll()).
> 

It is not yet released, so one can have a change to it, without much
hassles. Would you like to take a bite at it ? Anything to make it
better is always much appreciated, whether we use it or not for current
applications.

> Other than that, I think it's fine, or better: it doesn't do any harm.
> At the moment, I can only see that it adds another layer of indirection,
> but no real gain.
> 
> Especially, such a library shouldn't be an excuse for a bad API.
> 
> And, what's the big difference between a userspace library and an API?
> In what situation will the additional wrapper layer help compatibility?
> If we add a feature, we have to update the library as well. If we can do
> that in a backward compatible way, can't we do the same on the API?
> 

Since the issue maintaining backward compatibility is maintaining the
size of the older struct, which we avoid by copying causing an
additional layer of indirection in the kernel (dvb-core) The indirection
is a bit distributed to the library, such that it doesn't look ugly or bad.

In any case if we need backward compatibility, we need the indirection
somewhere. The only idea was to keep that in userspace, such that we
don't shoot ourselves in the foot.

Another thought was that an application using the library would be
usable straight away with multiple API's.
When the initial move was done, there were some thoughts of using some
other API's as well, hence the user_to_kapi definitions, ie the
indirection is handled in a nice way.

> I agree that it will help at this very moment, but as soon as
> applications need to deal  with different library versions, we have the
> same trouble again. Or did I misunderstand something? What can a library
> do what an API cannot do?

The idea was that the kernel change would not be visible to the end user
because of the additional indirection

> The alsa situation is a bit different - the alsa kernel api is very
> low-level, and needs some bells and whistles for easier usage. DVB is,
> fortunately, much easier to use. Our existing API is fine. (Agreed, if
> we ever add DMA buffers, we might need some helper app.)
> 
> Where I believe that we need a userspace helper is video processing (for
> handling records and proper playback using HW decoders), but for the
> frontend (or demux)?
> 

You don't get anything much large from it, except a layer of indirection
and a bit simplicity, such that the end application need not bother what
kernel API exits.

Manu


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

Re: [linux-dvb] DVB API update

[Felix Domke]

>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
> It is a nice idea, yes.
> Two things, looking at
> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
dvbfe_set imposes a certain programming scheme (because it sleeps). This
 is a total no-go for a generic library. I don't want a library telling
me that I have to use threads (instead of poll()).

Other than that, I think it's fine, or better: it doesn't do any harm.
At the moment, I can only see that it adds another layer of indirection,
but no real gain.

Especially, such a library shouldn't be an excuse for a bad API.

And, what's the big difference between a userspace library and an API?
In what situation will the additional wrapper layer help compatibility?
If we add a feature, we have to update the library as well. If we can do
that in a backward compatible way, can't we do the same on the API?

I agree that it will help at this very moment, but as soon as
applications need to deal  with different library versions, we have the
same trouble again. Or did I misunderstand something? What can a library
do what an API cannot do?

The alsa situation is a bit different - the alsa kernel api is very
low-level, and needs some bells and whistles for easier usage. DVB is,
fortunately, much easier to use. Our existing API is fine. (Agreed, if
we ever add DMA buffers, we might need some helper app.)

Where I believe that we need a userspace helper is video processing (for
handling records and proper playback using HW decoders), but for the
frontend (or demux)?

Felix

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Christophe Thommeret wrote:
> Le mardi 18 septembre 2007 18:41, Aidan Thornton a écrit :
>> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
 Markus Rechberger wrote:
> Hi,
>
>
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?
 It is a nice idea, yes.

 Two things, looking at
 http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c

 * This idea of using multiple API 's was thought (It is effective ,
 yes) You can use multiple API's in there

 * The down side is that user applications need to use this library

 Someone could ask, why the hell should we use your library. Well, that
 causes the headaches.
>>> people who use alsa also use the provided alsa API, it makes alot sense
>>> to stop applications to directly access those nodes. libdvbapi seems to
>>> be the right way to start over with.
>> I'm not sure ALSA is a good example - it's always felt a bit hairy to
>> me. Part of the reason that people have to use alsalib is that
>> important bits are in userland, and they tend to break in interesting
>> ways.
>>
>> For example, I found that if a program using ALSA launches another
>> program without closing the file descriptors correctly, sound playback
>> breaks when the first program exits due to the odd way software mixing
>> is done. There's various other annoying and non-intuitive ways that
>> software mixing can break too.
>>
>> (I also get the impression that ALSA uses the library as an excuse to
>> break kernel-userspace ABI compatibility, to the annoyance of distro
>> maintainers. I can certainly recall several complaints about it on
>> Diego "Flameeyes" Pettenò's blog back when he maintained ALSA on
>> Gentoo.)
>>
>> Besides, it's a bit late to try and do this now...
> 
> I also think it's a bit late.
> Kaffeine uses only the en50221 part of libdvbapi.
> Other parts was already implemented when libdvbapi came out, and i saw no 
> reason to drop that working code and implement a libdvbapi wrapper class ;)
> 

That clears it. Thanks for the clarification

Manu


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

Re: [linux-dvb] DVB API update

[Christophe Thommeret]

Le mardi 18 septembre 2007 18:41, Aidan Thornton a écrit :
> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > >
> > > > Why don't abstract the dvb layer from enduser applications and put a
> > > > general library infront which does that version check and tries to
> > > > keep things consistend to the end applications?
> > >
> > > It is a nice idea, yes.
> > >
> > > Two things, looking at
> > > http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> > >
> > > * This idea of using multiple API 's was thought (It is effective ,
> > > yes) You can use multiple API's in there
> > >
> > > * The down side is that user applications need to use this library
> > >
> > > Someone could ask, why the hell should we use your library. Well, that
> > > causes the headaches.
> >
> > people who use alsa also use the provided alsa API, it makes alot sense
> > to stop applications to directly access those nodes. libdvbapi seems to
> > be the right way to start over with.
>
> I'm not sure ALSA is a good example - it's always felt a bit hairy to
> me. Part of the reason that people have to use alsalib is that
> important bits are in userland, and they tend to break in interesting
> ways.
>
> For example, I found that if a program using ALSA launches another
> program without closing the file descriptors correctly, sound playback
> breaks when the first program exits due to the odd way software mixing
> is done. There's various other annoying and non-intuitive ways that
> software mixing can break too.
>
> (I also get the impression that ALSA uses the library as an excuse to
> break kernel-userspace ABI compatibility, to the annoyance of distro
> maintainers. I can certainly recall several complaints about it on
> Diego "Flameeyes" Pettenò's blog back when he maintained ALSA on
> Gentoo.)
>
> Besides, it's a bit late to try and do this now...

I also think it's a bit late.
Kaffeine uses only the en50221 part of libdvbapi.
Other parts was already implemented when libdvbapi came out, and i saw no 
reason to drop that working code and implement a libdvbapi wrapper class ;)

-- 
Christophe Thommeret


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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/18/07, Aidan Thornton <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > > Markus Rechberger wrote:
> > > > Hi,
> > > >
> > > >
> > > > Why don't abstract the dvb layer from enduser applications and put a
> > > > general library infront which does that version check and tries to
> > > > keep things consistend to the end applications?
> > >
> > > It is a nice idea, yes.
> > >
> > > Two things, looking at
> > > http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> > >
> > > * This idea of using multiple API 's was thought (It is effective ,
> yes)
> > > You can use multiple API's in there
> > >
> > > * The down side is that user applications need to use this library
> > >
> > > Someone could ask, why the hell should we use your library. Well, that
> > > causes the headaches.
> > >
> >
> > people who use alsa also use the provided alsa API, it makes alot sense
> > to stop applications to directly access those nodes. libdvbapi seems to
> be
> > the right way to start over with.
> >
>
> I'm not sure ALSA is a good example - it's always felt a bit hairy to
> me. Part of the reason that people have to use alsalib is that
> important bits are in userland, and they tend to break in interesting
> ways.
>
> For example, I found that if a program using ALSA launches another
> program without closing the file descriptors correctly, sound playback
> breaks when the first program exits due to the odd way software mixing
> is done. There's various other annoying and non-intuitive ways that
> software mixing can break too.
>
> (I also get the impression that ALSA uses the library as an excuse to
> break kernel-userspace ABI compatibility, to the annoyance of distro
> maintainers. I can certainly recall several complaints about it on
> Diego "Flameeyes" Pettenò's blog back when he maintained ALSA on
> Gentoo.)
>
> Besides, it's a bit late to try and do this now...
>

alsa is just an example in case of documentation and since it seems like
that the DVB API won't be stable in future either such a way would be better.

Markus

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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>  Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> Hi,
> >>>
> >>>
> >>> Why don't abstract the dvb layer from enduser applications and put a
> >>> general library infront which does that version check and tries to
> >>> keep things consistend to the end applications?
> >> It is a nice idea, yes.
> >>
> >> Two things, looking at
> >>
> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> >>
> >> * This idea of using multiple API 's was thought (It is effective ,
> >> yes)
> >> You can use multiple API's in there
> >>
> >> * The down side is that user applications need to use this library
> >>
> >> Someone could ask, why the hell should we use your library. Well,
> that
> >> causes the headaches.
> >>
> > people who use alsa also use the provided alsa API, it makes alot
> sense
> > to stop applications to directly access those nodes. libdvbapi seems
> to
> >> be
> > the right way to start over with.
>  If one can get applications to get going with it, it would be a start.
>  Someone jokingly said a name for it "ALDA". But many times, you can't
>  force things to users.
> >>> I just looked at it again, is there any official documentation
> available?
> >> There's nothing such as a libdvbapi.doc/txt. But the important parts
> >> were documented in the headers.*.h files
> >>
> >>
> >
> > I would say that's the reason why almost noone uses it. It would deserve
> some
> > more documentation on linuxtv.org
>
> Looking at the function names and what it does, it resembles the in
> kernel operations 1:1 also there is documentation in the headers. Also
> example applications, test applications, real working applications all
> exists in dvb-apps itself. You still think it needs more documentation ?
>

An abstract documentation and/or tutorial would still be better I think.
For example http://equalarea.com/paul/alsa-audio.html
It seems like people first have to ask in IRC or on the ML to get some info
about that library (well now people can also search that thread, although
an official documentation would be preferred I guess :)

Markus

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

Re: [linux-dvb] DVB API update

[Aidan Thornton]

On 9/18/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> > Markus Rechberger wrote:
> > > Hi,
> > >
> > >
> > > Why don't abstract the dvb layer from enduser applications and put a
> > > general library infront which does that version check and tries to
> > > keep things consistend to the end applications?
> >
> > It is a nice idea, yes.
> >
> > Two things, looking at
> > http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> >
> > * This idea of using multiple API 's was thought (It is effective , yes)
> > You can use multiple API's in there
> >
> > * The down side is that user applications need to use this library
> >
> > Someone could ask, why the hell should we use your library. Well, that
> > causes the headaches.
> >
>
> people who use alsa also use the provided alsa API, it makes alot sense
> to stop applications to directly access those nodes. libdvbapi seems to be
> the right way to start over with.
>

I'm not sure ALSA is a good example - it's always felt a bit hairy to
me. Part of the reason that people have to use alsalib is that
important bits are in userland, and they tend to break in interesting
ways.

For example, I found that if a program using ALSA launches another
program without closing the file descriptors correctly, sound playback
breaks when the first program exits due to the odd way software mixing
is done. There's various other annoying and non-intuitive ways that
software mixing can break too.

(I also get the impression that ALSA uses the library as an excuse to
break kernel-userspace ABI compatibility, to the annoyance of distro
maintainers. I can certainly recall several complaints about it on
Diego "Flameeyes" Pettenò's blog back when he maintained ALSA on
Gentoo.)

Besides, it's a bit late to try and do this now...

Aidan

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
 Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> Hi,
>>>
>>>
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to the end applications?
>> It is a nice idea, yes.
>>
>> Two things, looking at
>> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
>>
>> * This idea of using multiple API 's was thought (It is effective ,
>> yes)
>> You can use multiple API's in there
>>
>> * The down side is that user applications need to use this library
>>
>> Someone could ask, why the hell should we use your library. Well, that
>> causes the headaches.
>>
> people who use alsa also use the provided alsa API, it makes alot sense
> to stop applications to directly access those nodes. libdvbapi seems to
>> be
> the right way to start over with.
 If one can get applications to get going with it, it would be a start.
 Someone jokingly said a name for it "ALDA". But many times, you can't
 force things to users.
>>> I just looked at it again, is there any official documentation available?
>> There's nothing such as a libdvbapi.doc/txt. But the important parts
>> were documented in the headers.*.h files
>>
>>
> 
> I would say that's the reason why almost noone uses it. It would deserve some
> more documentation on linuxtv.org

Looking at the function names and what it does, it resembles the in
kernel operations 1:1 also there is documentation in the headers. Also
example applications, test applications, real working applications all
exists in dvb-apps itself. You still think it needs more documentation ?

Manu


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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>  Markus Rechberger wrote:
> > Hi,
> >
> >
> > Why don't abstract the dvb layer from enduser applications and put a
> > general library infront which does that version check and tries to
> > keep things consistend to the end applications?
>  It is a nice idea, yes.
> 
>  Two things, looking at
>  http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> 
>  * This idea of using multiple API 's was thought (It is effective ,
> yes)
>  You can use multiple API's in there
> 
>  * The down side is that user applications need to use this library
> 
>  Someone could ask, why the hell should we use your library. Well, that
>  causes the headaches.
> 
> >>> people who use alsa also use the provided alsa API, it makes alot sense
> >>> to stop applications to directly access those nodes. libdvbapi seems to
> be
> >>> the right way to start over with.
> >> If one can get applications to get going with it, it would be a start.
> >> Someone jokingly said a name for it "ALDA". But many times, you can't
> >> force things to users.
> >
> > I just looked at it again, is there any official documentation available?
>
> There's nothing such as a libdvbapi.doc/txt. But the important parts
> were documented in the headers.*.h files
>
>

I would say that's the reason why almost noone uses it. It would deserve some
more documentation on linuxtv.org

Markus

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Marcel Siegert wrote:
> Markus Rechberger schrieb:
> ---snip---
> 
>>
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
>> The enduser applications would have to implement that API one time but
>> it would help to keep unnecessary changes away from those applications
>> and even allow to clean up things lateron without breaking all the
>> applications... it's just a thought though..
>>
>> Markus
> markus,
> 
> even if i am ignored by you :)
> 
> if you would like to check out dvb-apps, you may find
> a libdvbapi and that is a kind of user space wrapper for
> such issues.
> i dont know if it is completely done, working, whatever, but the
> approach you want itself , was already started a long time ago.
> 
> i do not know how many people use this, but imho there are not so much.

Mws,

iirc, kaffeine was the first out of the dvb-apps tree user (other than
zap and gnutv)

Regards,
Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
 Markus Rechberger wrote:
> Hi,
>
>
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?
 It is a nice idea, yes.

 Two things, looking at
 http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c

 * This idea of using multiple API 's was thought (It is effective , yes)
 You can use multiple API's in there

 * The down side is that user applications need to use this library

 Someone could ask, why the hell should we use your library. Well, that
 causes the headaches.

>>> people who use alsa also use the provided alsa API, it makes alot sense
>>> to stop applications to directly access those nodes. libdvbapi seems to be
>>> the right way to start over with.
>> If one can get applications to get going with it, it would be a start.
>> Someone jokingly said a name for it "ALDA". But many times, you can't
>> force things to users.
> 
> I just looked at it again, is there any official documentation available?

There's nothing such as a libdvbapi.doc/txt. But the important parts
were documented in the headers.*.h files



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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> Markus Rechberger wrote:
> >>> Hi,
> >>>
> >>>
> >>> Why don't abstract the dvb layer from enduser applications and put a
> >>> general library infront which does that version check and tries to
> >>> keep things consistend to the end applications?
> >> It is a nice idea, yes.
> >>
> >> Two things, looking at
> >> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> >>
> >> * This idea of using multiple API 's was thought (It is effective , yes)
> >> You can use multiple API's in there
> >>
> >> * The down side is that user applications need to use this library
> >>
> >> Someone could ask, why the hell should we use your library. Well, that
> >> causes the headaches.
> >>
> >
> > people who use alsa also use the provided alsa API, it makes alot sense
> > to stop applications to directly access those nodes. libdvbapi seems to be
> > the right way to start over with.
>
> If one can get applications to get going with it, it would be a start.
> Someone jokingly said a name for it "ALDA". But many times, you can't
> force things to users.

I just looked at it again, is there any official documentation available?

Markus
> >>> The enduser applications would have to implement that API one time but
> >>> it would help to keep unnecessary changes away from those applications
> >>> and even allow to clean up things lateron without breaking all the
> >>> applications... it's just a thought though..
> >> Yes, that's how it would work in the ideal case, i doubt whether we can
> >> force applications to use the library.
> >>
> >
> > I would spend some time to implement such a library in enduser
> applications.
> > Although first I need to get my devices work and into the kernel and fix
> some
> > nasty bugs in my driver...
> >
> > Markus
> >
>
>


-- 
Markus Rechberger

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

Re: [linux-dvb] DVB API update

[Marcel Siegert]

Markus Rechberger schrieb:
---snip---

> 
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?
> The enduser applications would have to implement that API one time but
> it would help to keep unnecessary changes away from those applications
> and even allow to clean up things lateron without breaking all the
> applications... it's just a thought though..
> 
> Markus
markus,

even if i am ignored by you :)

if you would like to check out dvb-apps, you may find
a libdvbapi and that is a kind of user space wrapper for
such issues.
i dont know if it is completely done, working, whatever, but the
approach you want itself , was already started a long time ago.

i do not know how many people use this, but imho there are not so much.

regards
marcel

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Felix Domke wrote:

> BTW, this doesn't hold my "backward compatibility" request - if an
> application wants to tune a dvb-s transponder with the new api
> (DVBFE_SET_PARAMS), it won't run against an old api (which only
> implements FE_SET_FRONTEND, but could technically tune). But it seems
> that nobody else cares about this.
> 

I have put up the hacked version of the old szap, which works with both
the old and new API's
This just checks for the API version, which ioctl's to be used.

http://abraham.manu.googlepages.com/szap.c


Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Mauro Carvalho Chehab wrote:
> Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
> 
>>> I'm just interested on see things moving forward. Please stop with your
>>> flame wars. If you are not interested on serious discussions, you
>>> shouldn't have started the thread.
>> (bla, bla, bla)
> 
> If you can't technically argue about DVB API, but just want to play
> politics, you don't deserve any attention on that thread.
> 
> 

Missing context:

You don't have to try for that. See the userspace thread as well, where
you were misappropriating credits. So my case was not an isolated case.



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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Markus Rechberger wrote:
> On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> Markus Rechberger wrote:
>>> Hi,
>>>
>>>
>>> Why don't abstract the dvb layer from enduser applications and put a
>>> general library infront which does that version check and tries to
>>> keep things consistend to the end applications?
>> It is a nice idea, yes.
>>
>> Two things, looking at
>> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
>>
>> * This idea of using multiple API 's was thought (It is effective , yes)
>> You can use multiple API's in there
>>
>> * The down side is that user applications need to use this library
>>
>> Someone could ask, why the hell should we use your library. Well, that
>> causes the headaches.
>>
> 
> people who use alsa also use the provided alsa API, it makes alot sense
> to stop applications to directly access those nodes. libdvbapi seems to be
> the right way to start over with.

If one can get applications to get going with it, it would be a start.
Someone jokingly said a name for it "ALDA". But many times, you can't
force things to users.

>>> The enduser applications would have to implement that API one time but
>>> it would help to keep unnecessary changes away from those applications
>>> and even allow to clean up things lateron without breaking all the
>>> applications... it's just a thought though..
>> Yes, that's how it would work in the ideal case, i doubt whether we can
>> force applications to use the library.
>>
> 
> I would spend some time to implement such a library in enduser applications.
> Although first I need to get my devices work and into the kernel and fix some
> nasty bugs in my driver...
> 
> Markus
> 


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

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:

> > I'm just interested on see things moving forward. Please stop with your
> > flame wars. If you are not interested on serious discussions, you
> > shouldn't have started the thread.
>
> (bla, bla, bla)

If you can't technically argue about DVB API, but just want to play
politics, you don't deserve any attention on that thread.


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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Markus Rechberger wrote:
> > Hi,
> >
> >
> > Why don't abstract the dvb layer from enduser applications and put a
> > general library infront which does that version check and tries to
> > keep things consistend to the end applications?
>
> It is a nice idea, yes.
>
> Two things, looking at
> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
>
> * This idea of using multiple API 's was thought (It is effective , yes)
> You can use multiple API's in there
>
> * The down side is that user applications need to use this library
>
> Someone could ask, why the hell should we use your library. Well, that
> causes the headaches.
>

people who use alsa also use the provided alsa API, it makes alot sense
to stop applications to directly access those nodes. libdvbapi seems to be
the right way to start over with.

> > The enduser applications would have to implement that API one time but
> > it would help to keep unnecessary changes away from those applications
> > and even allow to clean up things lateron without breaking all the
> > applications... it's just a thought though..
>
> Yes, that's how it would work in the ideal case, i doubt whether we can
> force applications to use the library.
>

I would spend some time to implement such a library in enduser applications.
Although first I need to get my devices work and into the kernel and fix some
nasty bugs in my driver...

Markus

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Manu Abraham wrote:
> Markus Rechberger wrote:
>> Hi,
>>
>>
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
> 
> It is a nice idea, yes.
> 
> Two things, looking at
> http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c
> 
> * This idea of using multiple API 's was thought (It is effective , yes)
> You can use multiple API's in there
> 
> * The down side is that user applications need to use this library
> 
> Someone could ask, why the hell should we use your library. Well, that
> causes the headaches.
> 
>> The enduser applications would have to implement that API one time but
>> it would help to keep unnecessary changes away from those applications
>> and even allow to clean up things lateron without breaking all the
>> applications... it's just a thought though..
> 
> Yes, that's how it would work in the ideal case, i doubt whether we can
> force applications to use the library.


Although, IIRC, kaffeine uses it.

Manu


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Markus Rechberger wrote:
> Hi,
> 
> 
> Why don't abstract the dvb layer from enduser applications and put a
> general library infront which does that version check and tries to
> keep things consistend to the end applications?

It is a nice idea, yes.

Two things, looking at
http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c

* This idea of using multiple API 's was thought (It is effective , yes)
You can use multiple API's in there

* The down side is that user applications need to use this library

Someone could ask, why the hell should we use your library. Well, that
causes the headaches.

> The enduser applications would have to implement that API one time but
> it would help to keep unnecessary changes away from those applications
> and even allow to clean up things lateron without breaking all the
> applications... it's just a thought though..

Yes, that's how it would work in the ideal case, i doubt whether we can
force applications to use the library.

Manu


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

Re: [linux-dvb] DVB API update

[Markus Rechberger]

Hi,

On 9/18/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> Felix Domke wrote:
> > Manu Abraham wrote:
> >>> I'm not against mmap, I'm against using development resources for
> >>> implementing it. I can't see the big show-stopper in this issue.
> >>> So, seriously: Is there anybody here who *needs* this, based on his own
> >>> experience?
> >>> If yes, I'll might change my mind.
> >> I think it would be nice to have it.
> > Yes, it would be nice.
> >
> > But do you NEED it? Is it a show-stopper for you? Do you have a scenario
> > which doesn't work because of THIS?
>
> It is definitely not a show stopper, but as i said: It is a nice feature
> to be incorporated in to.
>
>
>  No, not throwing away anything, see my reply to Rainer. The newer
>  features will not be available with the older apps, that's all. You can
>  use the same drivers too. Backward compatibility is achieved by keeping
>  an additional set of ioctl's, so the old stuff will work as it is.
> >>> Will older hardware drivers be compatible with a new dvb-core (more than
> >>> maybe changing some identifiers)?
> >> As it is, without any change. I think Johannes did the great job of
> >> confusing people.
> > Don't get personal.
> >
> > Unstable driver APIs are a huge issue for non-mainstream hardware. Let's
> > do our best to keep devices without active maintainers supported. V4
> > would have killed them, so i only want to be sure that your "api
> > updates" won't.
> >
> >>> My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER.
> >>> [...]
> >> This sounds fine to me.
> > Great.
> >
> >>>  * "The current API doesn't allow you to do simple TS filters."
> >>>
> >>> Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up
> >>> with my solution, however people noted that this might break FF cards
> >>> due. This can probably be avoided by using a better value for
> DMX_TAP_TS.
> >>>
> >>> Note that the dvb-core implementation is trivial, as hardware drivers
> >>> are already supporting TS filtering. It's just not exposed to userspace.
> >> Mostly USB devices, afaik. Any other devices that you would like to
> >> mention ?
> > I don't understand this sentence. Any device not ignoring (a not-set)
> > TS_PAYLOAD_ONLY-flag should be compatible.
>
>
> I was thinking what all hardware would be having builtin hardware filters.
>
>
> >>>  * "The current API doesn't allow you to tune into -S2 transponders."
> >> We have solved this one already, drivers also exists, people watch S2
> >> What i pushed out last, is out here:
> >> http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2
> > ok. I don't like any part of the API (FE_SET_FRONTEND) to be obsoleted,
> > but ok, I can live with it. Please specify a bit more explictely which
> > parts of the API are mutually exclusive (FE_SET_FRONTEND vs.
> > DVBFE_SET_PARAMS). why are some IOCTLs called DVBFE_ and others FE_?
> >
> > BTW, this doesn't hold my "backward compatibility" request - if an
> > application wants to tune a dvb-s transponder with the new api
> > (DVBFE_SET_PARAMS), it won't run against an old api (which only
> > implements FE_SET_FRONTEND, but could technically tune). But it seems
> > that nobody else cares about this.
>
> The other option what i can think is to do a version check in the "new
> app", to selectively call the relevant ioctl.
>
>

Why don't abstract the dvb layer from enduser applications and put a
general library infront which does that version check and tries to
keep things consistend to the end applications?
The enduser applications would have to implement that API one time but
it would help to keep unnecessary changes away from those applications
and even allow to clean up things lateron without breaking all the
applications... it's just a thought though..

Markus

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Mauro Carvalho Chehab wrote:
> Em Ter, 2007-09-18 às 17:58 +0400, Manu Abraham escreveu:
>> Mauro Carvalho Chehab wrote:
>> And I think it would be wrong to delay DVB-S2 support until you
>> have all of DVB-H, DVB-T2, etc. properly hammered out.
>>> I have to agree with Johannes. The current 2.6 development model is
>>> based on "Commit earlier and commit often", as stated by Linus.
>>>
>> You should be out of your mind. Johannes only stated the one above and
>> he alone made the reply for it.
>>
>> Moreover you should be just interested in stealing other people's
>> credits. Now that many people are complaining on the same.
> 
> I'm just interested on see things moving forward. Please stop with your
> flame wars. If you are not interested on serious discussions, you
> shouldn't have started the thread.

You don't have to try for that. See the userspace thread as well, where
you were misappropriating credits. So my case was not an isolated case.



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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Felix Domke wrote:
> Manu Abraham wrote:
>>> I'm not against mmap, I'm against using development resources for
>>> implementing it. I can't see the big show-stopper in this issue.
>>> So, seriously: Is there anybody here who *needs* this, based on his own
>>> experience?
>>> If yes, I'll might change my mind.
>> I think it would be nice to have it.
> Yes, it would be nice.
> 
> But do you NEED it? Is it a show-stopper for you? Do you have a scenario
> which doesn't work because of THIS?

It is definitely not a show stopper, but as i said: It is a nice feature
to be incorporated in to.


 No, not throwing away anything, see my reply to Rainer. The newer
 features will not be available with the older apps, that's all. You can
 use the same drivers too. Backward compatibility is achieved by keeping
 an additional set of ioctl's, so the old stuff will work as it is.
>>> Will older hardware drivers be compatible with a new dvb-core (more than
>>> maybe changing some identifiers)?
>> As it is, without any change. I think Johannes did the great job of
>> confusing people.
> Don't get personal.
> 
> Unstable driver APIs are a huge issue for non-mainstream hardware. Let's
> do our best to keep devices without active maintainers supported. V4
> would have killed them, so i only want to be sure that your "api
> updates" won't.
> 
>>> My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER.
>>> [...]
>> This sounds fine to me.
> Great.
> 
>>>  * "The current API doesn't allow you to do simple TS filters."
>>>
>>> Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up
>>> with my solution, however people noted that this might break FF cards
>>> due. This can probably be avoided by using a better value for DMX_TAP_TS.
>>>
>>> Note that the dvb-core implementation is trivial, as hardware drivers
>>> are already supporting TS filtering. It's just not exposed to userspace.
>> Mostly USB devices, afaik. Any other devices that you would like to
>> mention ?
> I don't understand this sentence. Any device not ignoring (a not-set)
> TS_PAYLOAD_ONLY-flag should be compatible.


I was thinking what all hardware would be having builtin hardware filters.


>>>  * "The current API doesn't allow you to tune into -S2 transponders."
>> We have solved this one already, drivers also exists, people watch S2
>> What i pushed out last, is out here:
>> http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2
> ok. I don't like any part of the API (FE_SET_FRONTEND) to be obsoleted,
> but ok, I can live with it. Please specify a bit more explictely which
> parts of the API are mutually exclusive (FE_SET_FRONTEND vs.
> DVBFE_SET_PARAMS). why are some IOCTLs called DVBFE_ and others FE_?
> 
> BTW, this doesn't hold my "backward compatibility" request - if an
> application wants to tune a dvb-s transponder with the new api
> (DVBFE_SET_PARAMS), it won't run against an old api (which only
> implements FE_SET_FRONTEND, but could technically tune). But it seems
> that nobody else cares about this.

The other option what i can think is to do a version check in the "new
app", to selectively call the relevant ioctl.


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

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

Em Ter, 2007-09-18 às 17:58 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
>  And I think it would be wrong to delay DVB-S2 support until you
>  have all of DVB-H, DVB-T2, etc. properly hammered out.
> > 
> > I have to agree with Johannes. The current 2.6 development model is
> > based on "Commit earlier and commit often", as stated by Linus.
> > 
> 
> You should be out of your mind. Johannes only stated the one above and
> he alone made the reply for it.
> 
> Moreover you should be just interested in stealing other people's
> credits. Now that many people are complaining on the same.

I'm just interested on see things moving forward. Please stop with your
flame wars. If you are not interested on serious discussions, you
shouldn't have started the thread.

Mauro.


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

Re: [linux-dvb] DVB API update

[Felix Domke]

Manu Abraham wrote:
>> I'm not against mmap, I'm against using development resources for
>> implementing it. I can't see the big show-stopper in this issue.
>> So, seriously: Is there anybody here who *needs* this, based on his own
>> experience?
>> If yes, I'll might change my mind.
> I think it would be nice to have it.
Yes, it would be nice.

But do you NEED it? Is it a show-stopper for you? Do you have a scenario
which doesn't work because of THIS?

>>> No, not throwing away anything, see my reply to Rainer. The newer
>>> features will not be available with the older apps, that's all. You can
>>> use the same drivers too. Backward compatibility is achieved by keeping
>>> an additional set of ioctl's, so the old stuff will work as it is.
>> Will older hardware drivers be compatible with a new dvb-core (more than
>> maybe changing some identifiers)?
> As it is, without any change. I think Johannes did the great job of
> confusing people.
Don't get personal.

Unstable driver APIs are a huge issue for non-mainstream hardware. Let's
do our best to keep devices without active maintainers supported. V4
would have killed them, so i only want to be sure that your "api
updates" won't.

>> My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER.
>> [...]
> This sounds fine to me.
Great.

>>  * "The current API doesn't allow you to do simple TS filters."
>>
>> Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up
>> with my solution, however people noted that this might break FF cards
>> due. This can probably be avoided by using a better value for DMX_TAP_TS.
>>
>> Note that the dvb-core implementation is trivial, as hardware drivers
>> are already supporting TS filtering. It's just not exposed to userspace.
> Mostly USB devices, afaik. Any other devices that you would like to
> mention ?
I don't understand this sentence. Any device not ignoring (a not-set)
TS_PAYLOAD_ONLY-flag should be compatible.


>>  * "The current API doesn't allow you to tune into -S2 transponders."
> We have solved this one already, drivers also exists, people watch S2
> What i pushed out last, is out here:
> http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2
ok. I don't like any part of the API (FE_SET_FRONTEND) to be obsoleted,
but ok, I can live with it. Please specify a bit more explictely which
parts of the API are mutually exclusive (FE_SET_FRONTEND vs.
DVBFE_SET_PARAMS). why are some IOCTLs called DVBFE_ and others FE_?

BTW, this doesn't hold my "backward compatibility" request - if an
application wants to tune a dvb-s transponder with the new api
(DVBFE_SET_PARAMS), it won't run against an old api (which only
implements FE_SET_FRONTEND, but could technically tune). But it seems
that nobody else cares about this.

Felix

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Mauro Carvalho Chehab wrote:
 And I think it would be wrong to delay DVB-S2 support until you
 have all of DVB-H, DVB-T2, etc. properly hammered out.
> 
> I have to agree with Johannes. The current 2.6 development model is
> based on "Commit earlier and commit often", as stated by Linus.
> 

You should be out of your mind. Johannes only stated the one above and
he alone made the reply for it.

Moreover you should be just interested in stealing other people's
credits. Now that many people are complaining on the same.

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Felix Domke wrote:
> Manu Abraham wrote:
>> Felix Domke wrote:
>>> And now you try to complicate not only the API but also the device
>>> driver layer again, justified by a few percent CPU saving in a highly
>>> theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
>>> fits well together with hardware demuxes, but that's another topic.)
>> If people are against mmap, then i guess we can just abandon it.
> I'm not against mmap, I'm against using development resources for
> implementing it. I can't see the big show-stopper in this issue.
> 
> So, seriously: Is there anybody here who *needs* this, based on his own
> experience?
> 
> If yes, I'll might change my mind.


I think it would be nice to have it.


>> No, not throwing away anything, see my reply to Rainer. The newer
>> features will not be available with the older apps, that's all. You can
>> use the same drivers too. Backward compatibility is achieved by keeping
>> an additional set of ioctl's, so the old stuff will work as it is.
> Will older hardware drivers be compatible with a new dvb-core (more than
> maybe changing some identifiers)?

As it is, without any change. I think Johannes did the great job of
confusing people.

>>> (If want to discuss how we could improve the existing API to fix the
>>> problems mentioned above, I'd be happy to take part of it. I belive i
>>> have some simple, non-intrusive changes which take care of most of this
>>> stuff.)
>> Cool
> 
> ok, let's start:
> 
>  * "The current API doesn't even allow you to properly record more than
> one channel (unless you do re-filtering in userspace)."
> 
> This is because we have only this ugly "DVR filter" mechanism.
> 
> My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER.
> 
> See http://www.spinics.net/lists/linux-dvb/msg09258.html for details
> (the b.) part of it).

This sounds fine to me.

>  * "The current API doesn't allow you to do simple TS filters."
> 
> Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up
> with my solution, however people noted that this might break FF cards
> due. This can probably be avoided by using a better value for DMX_TAP_TS.
> 
> Note that the dvb-core implementation is trivial, as hardware drivers
> are already supporting TS filtering. It's just not exposed to userspace.

Mostly USB devices, afaik. Any other devices that you would like to
mention ?

> 
>  * "The current API doesn't allow you to tune into -S2 transponders."
> 

We have solved this one already, drivers also exists, people watch S2
streams as well

> I have to admit that I haven't followed the "multiproto" discussion much
> (i'm certainly not a frontend guy).

What i pushed out last, is out here:
http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2

It is a Hg tree as a tarball, uncompressing it, you can see the changes
in there.
(There are some changes local on my machine, which i haven't pushed out
yet, but basically most of it is there, the complexity hidden in dvb-core.)

> I'm happy here with any approach which doesn't break binary
> compatibility: A *new* application, compiled against new API headers,
> running on an *old* API should still be able to tune DVB-S, -C, -T (i.e.
> the currently supported delivery systems).
> 
>  * "The current API doesn't allow you to properly sync against a
> hardware decoder."
> 
> We have DMX_GET_STC, but I propose additionally a
> 
> VIDEO_GET_STC (in case you are playing without a demux, i.e. by writing
> data into video0),
> and
> VIDEO_GET_PTS, to get the PTS of the last displayed frame.

I don't have hardware decoders, use a SW decoder over here.

> 
>  * "It doesn't allow you to implement proper trick modes."
> For this I don't have a solution, and a proper trick mode playback is
> probably out of scope for this API.  It's probably not too interesting
> for non-embedded platforms with hardware decoders.
> 
> Take the example of a playing an mpeg stream backwards. This includes
> parsing the frame types, issuing frames in the correct order together
> with private instructions for the MPEG decoder on which pictures should
> be displayed and which one should not.  I'm not sure if this can even be
> handled in a generic, hardware-independent way, so it will be a hard part.


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

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

> > > And I think it would be wrong to delay DVB-S2 support until you
> > > have all of DVB-H, DVB-T2, etc. properly hammered out.

I have to agree with Johannes. The current 2.6 development model is
based on "Commit earlier and commit often", as stated by Linus.

This means that a big trouble can (and should) be split into smaller
troubles and cleaner solutions.

This also means that the life cycle for adding newer functionalities in
kernel shouldn't take a large amount of time.

If we wait for finishing V4 API to support DVB-S2, some drivers, already
written, should wait, losing their time to market (In fact, they are
already late). I don't see any reason for postponing it more.

On the other hand, userspace API should be forever. So, changes should
be done in a way to avoid breaking binary compatibility with userspace
apps. So, an extra care should be taken to avoid creating APIs that may
need to be changed in a near future. One possible way to try to solve
this dilema is to mark the newer API changes as EXPERIMENTAL, for quite
a few kernel versions.

Anyway, IMO, we should prioritize DVB-S2 and multiple frontend support
(for hybrid DVB-T/DVB-C boards). This doesn't mean that we should forget
the other targets. For example, I'm interested on ARIB extensions, since
we should be working soon on an ISDB-T board for Brazil's market.

Cheers,
Mauro.


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

Re: [linux-dvb] DVB API update

[Felix Domke]

Manu Abraham wrote:
> Felix Domke wrote:
>> And now you try to complicate not only the API but also the device
>> driver layer again, justified by a few percent CPU saving in a highly
>> theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
>> fits well together with hardware demuxes, but that's another topic.)
> If people are against mmap, then i guess we can just abandon it.
I'm not against mmap, I'm against using development resources for
implementing it. I can't see the big show-stopper in this issue.

So, seriously: Is there anybody here who *needs* this, based on his own
experience?

If yes, I'll might change my mind.

> No, not throwing away anything, see my reply to Rainer. The newer
> features will not be available with the older apps, that's all. You can
> use the same drivers too. Backward compatibility is achieved by keeping
> an additional set of ioctl's, so the old stuff will work as it is.
Will older hardware drivers be compatible with a new dvb-core (more than
maybe changing some identifiers)?

>> (If want to discuss how we could improve the existing API to fix the
>> problems mentioned above, I'd be happy to take part of it. I belive i
>> have some simple, non-intrusive changes which take care of most of this
>> stuff.)
> Cool

ok, let's start:

 * "The current API doesn't even allow you to properly record more than
one channel (unless you do re-filtering in userspace)."

This is because we have only this ugly "DVR filter" mechanism.

My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER.

See http://www.spinics.net/lists/linux-dvb/msg09258.html for details
(the b.) part of it).

 * "The current API doesn't allow you to do simple TS filters."

Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up
with my solution, however people noted that this might break FF cards
due. This can probably be avoided by using a better value for DMX_TAP_TS.

Note that the dvb-core implementation is trivial, as hardware drivers
are already supporting TS filtering. It's just not exposed to userspace.

 * "The current API doesn't allow you to tune into -S2 transponders."

I have to admit that I haven't followed the "multiproto" discussion much
(i'm certainly not a frontend guy).

My naive approach back then was to implement a "FE_SET_SYSTEM"-ioctl,
which would specificy the system ("DVB-S2" for example) for the
frontend. The following FE_SET_FRONTEND etc. would operate on the
previously set system, with their own structure (not necessarily a union
of all supported types anymore). There have been a number of counter
arguments of this approach, and it predated the "multiproto" stuff, so
this is probably obsolete.

I'm happy here with any approach which doesn't break binary
compatibility: A *new* application, compiled against new API headers,
running on an *old* API should still be able to tune DVB-S, -C, -T (i.e.
the currently supported delivery systems).

 * "The current API doesn't allow you to properly sync against a
hardware decoder."

We have DMX_GET_STC, but I propose additionally a

VIDEO_GET_STC (in case you are playing without a demux, i.e. by writing
data into video0),
and
VIDEO_GET_PTS, to get the PTS of the last displayed frame.


 * "It doesn't allow you to implement proper trick modes."
For this I don't have a solution, and a proper trick mode playback is
probably out of scope for this API.  It's probably not too interesting
for non-embedded platforms with hardware decoders.

Take the example of a playing an mpeg stream backwards. This includes
parsing the frame types, issuing frames in the correct order together
with private instructions for the MPEG decoder on which pictures should
be displayed and which one should not.  I'm not sure if this can even be
handled in a generic, hardware-independent way, so it will be a hard part.

Felix

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Georg Acher wrote:
> On Tue, Sep 18, 2007 at 03:33:25PM +0400, Manu Abraham wrote:
>  
>>> I have h.264 playback running on a really slow Geode with 300MHz. For a
>>> 15Mbit/s stream, the TS path from the DMA buffers into user space needs
>>> about 5% CPU with traditional memcpy(). I wouldn't call that optimization
>>> worthy... What really counts is the postprocessing in user space (remuxing,
>>> repacking, etc.). The API may support this with single PIDs per
>>> read filedescriptor, but I don't think it makes a difference where the data
>>> is actually filtered...
>>>
>> You are looking at a single DVB-S2 demod. There are dual S2 demods in a
>> single chip config.
>> Consider that with multiple adapters, even if you ignore post processing.
> 
> But you wouldn't use a 300MHz CPU for that anyway, because it has no CPU
> power to do something else with the stream. I'm certainly the last who is
> against optimization, but I don't see the case here to put much effort in
> that.

Consider a situation, even for a STB (I am not stating that a STB is the
only application)

Dual config demod cores on a single chip, the device having more than
one demod. This results in a minimum of 4 streams, with the remux
overhead considered (i am not saying here is that it will kill your
embedded CPU) but it will *be* a significant overhead.


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

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

On Tue, Sep 18, 2007 at 02:26:13PM +0200, Georg Acher wrote:
> The Reelbox (with the 300MHz) has up to 4 tuners, the NetCeiver can have up
> to 6 tuners (max 40Mbyte/s input rate). I did a lot of profiling
> (oprofile/gprof) on the Geode, so I think I know what multi demods can "do"
> with the system.
> 
> But the real performance problems appear in user space, not in the kernel.
> Eg. vdr uses two additional ringbuffers to move the TS around (10% for one
> channel). vdr's EPG parsing on the ARD transponder can take initially more
> than 40% CPU (on the Geode). Repacking a simple SDTV-Stream with 6Mbits/s
> into PES takes another 15-20%. Compared to that, the DVB subsystem is
> neglectable... With faster CPUs (better memory system, larger caches) I
> expect the impact to be even less.

Thanks for the numbers, Georg!

That was all my previous posting was about, so now we know these facts,
my objections can be ignored, I think.

Regards,
Wolfgang


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Felix Domke wrote:
> Sorry to give my two cents, but...
> 
> Manu Abraham wrote:
>> The case of a 20Mbps stream getting recorded is not a great thing. when
>> you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
>> normal TS itself is about 27Mbps (in a very crude rounded off case)
>> So, the situation that you have isn't larger than a situation having a
>> normal single DVB-S card.
> The current API doesn't even allow you to properly record more than one
> channel (unless you do re-filtering in userspace).
> 
> The current API doesn't allow you to do simple TS filters.
> 
> The current API doesn't allow you to tune into -S2 transponders.
> 
> The current API doesn't allow you to properly sync against a hardware
> decoder. It doesn't allow you to implement proper trick modes.
> 
> That are all real-world problems. Explain a *user* why he can't record
> two channels at once, just because the API doesn't let you do that!
> 
> None of these problems get solved with the current v4 aproach, simply
> because the API is unfinished, the implementation non-final, and there
> are, how many?, like *2* hardware devices supported, and not a single
> real userspace application using that API.
> 
> Yes, technically it could solve everything, but practically, it doesn't
> help a bit.
> 
> And now you try to complicate not only the API but also the device
> driver layer again, justified by a few percent CPU saving in a highly
> theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
> fits well together with hardware demuxes, but that's another topic.)

If people are against mmap, then i guess we can just abandon it.

> 
> If your argument is "embedded processors have less power": Yes, they
> have. But a normal embedded 300Mhz CPU will still be able to record two
> complete TS streams to HDD, including all userspace overhead, with a
> software demux. The problem you're talking about is just not a real
> world problem, not even on slow systems with a memcpy()-performance
> <100MB/s.
> 
> If we solve this problem like we have "solved" it last time (inventing
> an API which is so complex that nobody implements or uses), we won't
> ever fix the real world problems stated above.
> 
> Keep it simple, *please*. Improve it gradually. Don't throw away
> everything (device support, user base, source/binary compatibility) for
> fixing a non-issue.

No, not throwing away anything, see my reply to Rainer. The newer
features will not be available with the older apps, that's all. You can
use the same drivers too. Backward compatibility is achieved by keeping
an additional set of ioctl's, so the old stuff will work as it is.

Although you will need adjustments for the statistics, but that
shouldn't pose a big issue.

> The current API is fine. It really needs some tweaks here and there, but
> otherwise it's ok.
> 
> (If want to discuss how we could improve the existing API to fix the
> problems mentioned above, I'd be happy to take part of it. I belive i
> have some simple, non-intrusive changes which take care of most of this
> stuff.)

Cool

Thanks,
Manu


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

Re: [linux-dvb] DVB API update

[Georg Acher]

On Tue, Sep 18, 2007 at 03:33:25PM +0400, Manu Abraham wrote:
 
> > I have h.264 playback running on a really slow Geode with 300MHz. For a
> > 15Mbit/s stream, the TS path from the DMA buffers into user space needs
> > about 5% CPU with traditional memcpy(). I wouldn't call that optimization
> > worthy... What really counts is the postprocessing in user space (remuxing,
> > repacking, etc.). The API may support this with single PIDs per
> > read filedescriptor, but I don't think it makes a difference where the data
> > is actually filtered...
> > 
> 
> You are looking at a single DVB-S2 demod. There are dual S2 demods in a
> single chip config.
> Consider that with multiple adapters, even if you ignore post processing.

But you wouldn't use a 300MHz CPU for that anyway, because it has no CPU
power to do something else with the stream. I'm certainly the last who is
against optimization, but I don't see the case here to put much effort in
that.

> If you have a larger number of adapters and you have to do post
> processing, there is quite a large unnecessary overhead, even if you
> don't do software decoding.
> 
> Are there only a very few people having multiple DVB adapters in a PC ?
> (I guess people having dual and quad demods (single demod/chip) on an
> adapter and having multiple adapters can be quite a small fraction)

The Reelbox (with the 300MHz) has up to 4 tuners, the NetCeiver can have up
to 6 tuners (max 40Mbyte/s input rate). I did a lot of profiling
(oprofile/gprof) on the Geode, so I think I know what multi demods can "do"
with the system.

But the real performance problems appear in user space, not in the kernel.
Eg. vdr uses two additional ringbuffers to move the TS around (10% for one
channel). vdr's EPG parsing on the ARD transponder can take initially more
than 40% CPU (on the Geode). Repacking a simple SDTV-Stream with 6Mbits/s
into PES takes another 15-20%. Compared to that, the DVB subsystem is
neglectable... With faster CPUs (better memory system, larger caches) I
expect the impact to be even less.

-- 
 Georg Acher, [EMAIL PROTECTED]
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias

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

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

On Mon, Sep 17, 2007 at 11:17:19PM +0200, Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
> > 
> > If you would like to fix that in V3, i would much appreciate. If you
> > would just like to keep talking only, maybe lets then not talk too much
> > about it.
> 
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But to be honest, I don't think
> it's important on a PC which can copy > 1GByte/s in RAM. More
> interesting would be the ability to have multiple independant filtered
> TS outputs instead of just one dvr device.

Sorry to quote here, but this seems to be the start of a longer
discussion.

I personally have no experience with more than one DVB card, but how
about a "DVB streaming server"? AFAIK this is possible with current
linuxdvb and VDR, and this could be an even more interesting target
if more and more streaming clients are available.
Of course, current PCs do have a huge amount of bandwidth resources,
but such a device should be low-power, and so a not so powerful CPU
would be preferred. From former experiments I know that a 266 MHz Geode
does in fact have significant load when simply streaming two or three
SDTV streams from the same transponder - but as this is about 5 years
ago, I do not recall the exact numbers.

Again, personally I do not have much experience with the demux except
using it, but the discussion got quite emotional, so I want to try
to reduce it to use cases and pros/cons of different approaches.

Best regards,
Wolfgang


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

Re: [linux-dvb] DVB API update

[Felix Domke]

Sorry to give my two cents, but...

Manu Abraham wrote:
> The case of a 20Mbps stream getting recorded is not a great thing. when
> you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
> normal TS itself is about 27Mbps (in a very crude rounded off case)
> So, the situation that you have isn't larger than a situation having a
> normal single DVB-S card.
The current API doesn't even allow you to properly record more than one
channel (unless you do re-filtering in userspace).

The current API doesn't allow you to do simple TS filters.

The current API doesn't allow you to tune into -S2 transponders.

The current API doesn't allow you to properly sync against a hardware
decoder. It doesn't allow you to implement proper trick modes.

That are all real-world problems. Explain a *user* why he can't record
two channels at once, just because the API doesn't let you do that!

None of these problems get solved with the current v4 aproach, simply
because the API is unfinished, the implementation non-final, and there
are, how many?, like *2* hardware devices supported, and not a single
real userspace application using that API.

Yes, technically it could solve everything, but practically, it doesn't
help a bit.

And now you try to complicate not only the API but also the device
driver layer again, justified by a few percent CPU saving in a highly
theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers
fits well together with hardware demuxes, but that's another topic.)

If your argument is "embedded processors have less power": Yes, they
have. But a normal embedded 300Mhz CPU will still be able to record two
complete TS streams to HDD, including all userspace overhead, with a
software demux. The problem you're talking about is just not a real
world problem, not even on slow systems with a memcpy()-performance
<100MB/s.

If we solve this problem like we have "solved" it last time (inventing
an API which is so complex that nobody implements or uses), we won't
ever fix the real world problems stated above.

Keep it simple, *please*. Improve it gradually. Don't throw away
everything (device support, user base, source/binary compatibility) for
fixing a non-issue.

The current API is fine. It really needs some tweaks here and there, but
otherwise it's ok.

(If want to discuss how we could improve the existing API to fix the
problems mentioned above, I'd be happy to take part of it. I belive i
have some simple, non-intrusive changes which take care of most of this
stuff.)

Felix

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Rudy Zijlstra wrote:
> Manu Abraham wrote:
>> Georg Acher wrote:
>>  
>>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>>>  
>>>
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But to be honest, I don't think
> it's important on a PC which can copy > 1GByte/s in RAM. More
> interesting would be the ability to have multiple independant filtered
> TS outputs instead of just one dvr device.
> 
 Currently have you tried playing back a High Bit rate H.264 stream
 default of a DVB-S2 stream ? I guess not.

 If you have had, you will see my reasons why i am trying to optimize
 the
 overheads.
 BTW: it is not RAM that matters here, but CPU horsepower
   
>>> I have h.264 playback running on a really slow Geode with 300MHz. For a
>>> 15Mbit/s stream, the TS path from the DMA buffers into user space needs
>>> about 5% CPU with traditional memcpy(). I wouldn't call that
>>> optimization
>>> worthy... What really counts is the postprocessing in user space
>>> (remuxing,
>>> repacking, etc.). The API may support this with single PIDs per
>>> read filedescriptor, but I don't think it makes a difference where
>>> the data
>>> is actually filtered...
>>>
>>> 
>>
>> You are looking at a single DVB-S2 demod. There are dual S2 demods in a
>> single chip config.
>> Consider that with multiple adapters, even if you ignore post processing.
>>
>> If you have a larger number of adapters and you have to do post
>> processing, there is quite a large unnecessary overhead, even if you
>> don't do software decoding.
>>
>> Are there only a very few people having multiple DVB adapters in a PC ?
>> (I guess people having dual and quad demods (single demod/chip) on an
>> adapter and having multiple adapters can be quite a small fraction)
>>   
> 2 systems with each 4 DVB tuners. test system has 3 DVB-S + 1 DVB-C.
> operational its 4x DVB-S
> 
> The DVB-C is capturing H.264 though and not problems in capturing.
> 
> capturing and demux is not the problem. Displaying it (postprocessing) is.


True, the issue with post processing seems to be open ended.



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

Re: [linux-dvb] DVB API update

[Rudy Zijlstra]

Manu Abraham wrote:
> Georg Acher wrote:
>   
>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>>  
>> 
 The recording filters are exactly the piece from V4 which has the
 "mmap DMA buffers" zero copy API. But to be honest, I don't think
 it's important on a PC which can copy > 1GByte/s in RAM. More
 interesting would be the ability to have multiple independant filtered
 TS outputs instead of just one dvr device.
 
>>> Currently have you tried playing back a High Bit rate H.264 stream
>>> default of a DVB-S2 stream ? I guess not.
>>>
>>> If you have had, you will see my reasons why i am trying to optimize the
>>> overheads.
>>> BTW: it is not RAM that matters here, but CPU horsepower
>>>   
>> I have h.264 playback running on a really slow Geode with 300MHz. For a
>> 15Mbit/s stream, the TS path from the DMA buffers into user space needs
>> about 5% CPU with traditional memcpy(). I wouldn't call that optimization
>> worthy... What really counts is the postprocessing in user space (remuxing,
>> repacking, etc.). The API may support this with single PIDs per
>> read filedescriptor, but I don't think it makes a difference where the data
>> is actually filtered...
>>
>> 
>
> You are looking at a single DVB-S2 demod. There are dual S2 demods in a
> single chip config.
> Consider that with multiple adapters, even if you ignore post processing.
>
> If you have a larger number of adapters and you have to do post
> processing, there is quite a large unnecessary overhead, even if you
> don't do software decoding.
>
> Are there only a very few people having multiple DVB adapters in a PC ?
> (I guess people having dual and quad demods (single demod/chip) on an
> adapter and having multiple adapters can be quite a small fraction)
>   
2 systems with each 4 DVB tuners. test system has 3 DVB-S + 1 DVB-C. 
operational its 4x DVB-S

The DVB-C is capturing H.264 though and not problems in capturing.

capturing and demux is not the problem. Displaying it (postprocessing) is.

Cheers,

Rudy

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

Re: [linux-dvb] DVB API update

[Rudy Zijlstra]

Manu Abraham wrote:
> Janne Grunau wrote:
>   
>> On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
>> 
>>> Johannes Stezenbach wrote:
>>>   
 On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
 
> Johannes Stezenbach wrote:
>   
>> The recording filters are exactly the piece from V4 which has the
>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>> it's important on a PC which can copy > 1GByte/s in RAM. More
>> interesting would be the ability to have multiple independant
>> filtered TS outputs instead of just one dvr device.
>> 
> Currently have you tried playing back a High Bit rate H.264 stream
> default of a DVB-S2 stream ? I guess not.
>
> If you have had, you will see my reasons why i am trying to
> optimize the overheads.
> BTW: it is not RAM that matters here, but CPU horsepower
>   
 A demux doesn't decode, and what matters is memory bandwidth.
 
>>> Try running a software decoder alongwith and tell me that that
>>> decoding doesn't need CPU
>>>   
>> right the software decoder needs cpu power.
>>
>> 
>>> and then the options what you can look at 
>>> is cutting whatever overheads it is.
>>>   
>> Wrong, you would start optimizing parts with take significant time. I 
>> can record 20mbps streams on a machine capable of decoding H264 1080p 
>> video with more than 99 percent idle. So even if you can optimize 
>> capturing the stream to taking zero cpu cycles (and you can't) you will  
>> see at most 1% increase in decoding speed.
>> 
>
>
> The case of a 20Mbps stream getting recorded is not a great thing. when
> you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
> normal TS itself is about 27Mbps (in a very crude rounded off case)
>
> So, the situation that you have isn't larger than a situation having a
> normal single DVB-S card.
>
>   

A single DVB-C card can go up to about 55Mbps when using QAM256...

And more and more operators are now using QAM256 on cable.

Cheers,

Rudy

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Janne Grunau wrote:
> On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
 Johannes Stezenbach wrote:
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But to be honest, I don't think
> it's important on a PC which can copy > 1GByte/s in RAM. More
> interesting would be the ability to have multiple independant
> filtered TS outputs instead of just one dvr device.
 Currently have you tried playing back a High Bit rate H.264 stream
 default of a DVB-S2 stream ? I guess not.

 If you have had, you will see my reasons why i am trying to
 optimize the overheads.
 BTW: it is not RAM that matters here, but CPU horsepower
>>> A demux doesn't decode, and what matters is memory bandwidth.
>> Try running a software decoder alongwith and tell me that that
>> decoding doesn't need CPU
> 
> right the software decoder needs cpu power.
> 
>> and then the options what you can look at 
>> is cutting whatever overheads it is.
> 
> Wrong, you would start optimizing parts with take significant time. I 
> can record 20mbps streams on a machine capable of decoding H264 1080p 
> video with more than 99 percent idle. So even if you can optimize 
> capturing the stream to taking zero cpu cycles (and you can't) you will  
> see at most 1% increase in decoding speed.


The case of a 20Mbps stream getting recorded is not a great thing. when
you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the
normal TS itself is about 27Mbps (in a very crude rounded off case)

So, the situation that you have isn't larger than a situation having a
normal single DVB-S card.


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Georg Acher wrote:
> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>  
>>> The recording filters are exactly the piece from V4 which has the
>>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>>> it's important on a PC which can copy > 1GByte/s in RAM. More
>>> interesting would be the ability to have multiple independant filtered
>>> TS outputs instead of just one dvr device.
>> Currently have you tried playing back a High Bit rate H.264 stream
>> default of a DVB-S2 stream ? I guess not.
>>
>> If you have had, you will see my reasons why i am trying to optimize the
>> overheads.
>> BTW: it is not RAM that matters here, but CPU horsepower
> 
> I have h.264 playback running on a really slow Geode with 300MHz. For a
> 15Mbit/s stream, the TS path from the DMA buffers into user space needs
> about 5% CPU with traditional memcpy(). I wouldn't call that optimization
> worthy... What really counts is the postprocessing in user space (remuxing,
> repacking, etc.). The API may support this with single PIDs per
> read filedescriptor, but I don't think it makes a difference where the data
> is actually filtered...
> 

You are looking at a single DVB-S2 demod. There are dual S2 demods in a
single chip config.
Consider that with multiple adapters, even if you ignore post processing.

If you have a larger number of adapters and you have to do post
processing, there is quite a large unnecessary overhead, even if you
don't do software decoding.

Are there only a very few people having multiple DVB adapters in a PC ?
(I guess people having dual and quad demods (single demod/chip) on an
adapter and having multiple adapters can be quite a small fraction)


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

Re: [linux-dvb] DVB API update

[Georg Acher]

On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
 
> > The recording filters are exactly the piece from V4 which has the
> > "mmap DMA buffers" zero copy API. But to be honest, I don't think
> > it's important on a PC which can copy > 1GByte/s in RAM. More
> > interesting would be the ability to have multiple independant filtered
> > TS outputs instead of just one dvr device.
> 
> Currently have you tried playing back a High Bit rate H.264 stream
> default of a DVB-S2 stream ? I guess not.
> 
> If you have had, you will see my reasons why i am trying to optimize the
> overheads.
> BTW: it is not RAM that matters here, but CPU horsepower

I have h.264 playback running on a really slow Geode with 300MHz. For a
15Mbit/s stream, the TS path from the DMA buffers into user space needs
about 5% CPU with traditional memcpy(). I wouldn't call that optimization
worthy... What really counts is the postprocessing in user space (remuxing,
repacking, etc.). The API may support this with single PIDs per
read filedescriptor, but I don't think it makes a difference where the data
is actually filtered...

-- 
 Georg Acher, [EMAIL PROTECTED]
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias

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

Re: [linux-dvb] DVB API update

[KeNroM]

did any of u guys worked on a project called DM100-B for
caribbeandreambox.com?

On 9/17/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>
> Johannes Stezenbach wrote:
> > On Mon, Sep 17, 2007, Steven Toth wrote:
> >> Johannes Stezenbach wrote:
> >>> But after all the discussions, and you and Steve have written
> >>> drivers which I hope prove the API as working, why do you
> >>> still think it is experimental? What would it take to make
> >>> it non-experimental?
> >> My take on the patches is this:
> >>
> >> It's experimental.
> >>
> >> However, it's been experimental for about a year and it's not getting
> >> traction, I've said this before on the ML - it needs to be driven. I've
> >> been pinging Manu recently to put up a tree on linuxtv.org/hg, merged
> with
> >> the latest v4l-dvb tree so people like myself can start testing,
> breaking
> >> and patching the tree.
> >>
> >> No tree = no testers = no discussion = no review = no merge = no
> support in
> >> Linux.
> >>
> >> I want to help start the ball rolling.
> >
> > Great, sounds like a good plan.
> >
> >>> I wish you'd just stop with all those private discussions and instead
> >>> keep it on the list all the time. That way everyone would have all
> >>> the relevant information, which is one of the key points of doing
> >>> Open Source development: spreading not just the code but also the
> >>> knowledge about the technology. mrec isn't completely wrong when he
> says
> >>> that this list gives the appearance of a closed, elitist circle where
> >>> everything interesting happens in backrooms.
> >> That's a little harsh Johannes. :)
> >
> > But I mean it. I used clear words so everyone would get it.
>
>
> from the Userspace tuner thread:
>
> "Manu throws his drivers over the wall to the OSS community, although
> I don't mind.
> Mauro is copying the logic of my code and writes I told him I'm ok with
> taking my code without just adding a single line of how his driver
> got developed. (I still wonder why he skipped some significant parts
> of the driver .. because he used the existing one as logic template)
>
>
> http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
> (not looking at the specific changeset but he copied the firmware
> loading instructions without taking care about the copyright?)"
>
>
> Manu
>
> ___
> 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] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Steven Toth wrote:
>> Johannes Stezenbach wrote:
>>> But after all the discussions, and you and Steve have written
>>> drivers which I hope prove the API as working, why do you
>>> still think it is experimental? What would it take to make
>>> it non-experimental?
>> My take on the patches is this:
>>
>> It's experimental.
>>
>> However, it's been experimental for about a year and it's not getting 
>> traction, I've said this before on the ML - it needs to be driven. I've 
>> been pinging Manu recently to put up a tree on linuxtv.org/hg, merged with 
>> the latest v4l-dvb tree so people like myself can start testing, breaking 
>> and patching the tree.
>>
>> No tree = no testers = no discussion = no review = no merge = no support in 
>> Linux.
>>
>> I want to help start the ball rolling.
> 
> Great, sounds like a good plan.
> 
>>> I wish you'd just stop with all those private discussions and instead
>>> keep it on the list all the time. That way everyone would have all
>>> the relevant information, which is one of the key points of doing
>>> Open Source development: spreading not just the code but also the
>>> knowledge about the technology. mrec isn't completely wrong when he says
>>> that this list gives the appearance of a closed, elitist circle where
>>> everything interesting happens in backrooms.
>> That's a little harsh Johannes. :)
> 
> But I mean it. I used clear words so everyone would get it.


from the Userspace tuner thread:

"Manu throws his drivers over the wall to the OSS community, although
I don't mind.
Mauro is copying the logic of my code and writes I told him I'm ok with
taking my code without just adding a single line of how his driver
got developed. (I still wonder why he skipped some significant parts
of the driver .. because he used the existing one as logic template)

http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
(not looking at the specific changeset but he copied the firmware
loading instructions without taking care about the copyright?)"


Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
>> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>>   to see ASI here...
> 
> See my other mail, IMHO we should add the ASI defines at
> the same time we merge a driver which uses it.
> 
>> - frontend status:
>>   - BER is lacking a proper definition (to which base is it calculated?)
>>   - signal strength: same problem, what are the ranges?
>>   - snr: again, no base and ranges given
> 
> The original Nokia DVB API spec had proper definitions, but
> Holger Waechtler and me decided to drop them in favour of
> "read hw register and scale to range 0..0x". The reasons
> for this were:
> - for some hw we didn't have info to implement it properly
> - for those hw where we had info we saw it wasn't worth the
>   effort -- I believe the implementation in the demod firmware
>   is just such a coarse approximation that it doesn't
>   even make a difference if you take the logarithm or not
>   (provided you scale back into the 16bit range)
>   (of course you get different numbers, but none of them
>   maps any better to what you'd expect)
> 

As an example, BER is not just a dump of some registers. It depends on
the symbols being acquired, averaged etc. If you have a lower symbol
rate, you have a larger acquisition time frame, also lower the symbols,
the larger the number of snapshots required for proper averaging.

Also when you start a measurement, all of it has to be ideally at the
same snapshot of time, eventhough you can't get the exact same snapshot,
you must be somewhere quite near.

Just take a look over here:
http://www.dsprelated.com/showmessage/33285/1.php

No wonder it is so hopeless.

HTH
Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>> forever on the same thing.
> 
> Exactly, that's why I blocked your initial attempt to merge the
> DVB-S2 API extensions. *That* it was experimental code (even
> completely untested).
> 
> But after all the discussions, and you and Steve have written
> drivers which I hope prove the API as working, why do you
> still think it is experimental? What would it take to make
> it non-experimental?
> 
>> I would prefer to say mark it experimental in
>> a tree dedicated to it, such that it is explicitly stated that it is not
>> a permanent solution and in the background, the fixes required for the
>> relevant can be done.
> 
> IMHO application developers hate temporary APIs -- it means they
> have to rewrite their code later, and there are zero guarantees
> as to when you make the change to the "real" API and how big the
> required changes would be.
> 

[snip]

> I really don't think there is any problem in releasing API version 3.3
> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
> 


" I'm still not sure about the DVB-S2 API. So I would prefer
if the whole change would not be merged into mainline
until there is at least one fully functional DVB-S2 driver
in the tree (i.e. keep it in a v4l-dvb-s2 repo for now).

If you think this is too much hassle, then at least
mark the DVB-S2 stuff as "EXPERIMENTAL / DO NOT USE / SUBJECT
TO CHANGE WITHOUT NOTICE" (in capitals). So that you can
break binary and source compatibilty for the DVB-S2 part
with clean conscience until it is proven stable.

Agreed?


Johannes"


Someone by name Johannes Stezenbach wrote this, while the intend was to
do the minimalistic approach with DVB-S2 (ie, without the advanced
features of DVB-S2) ;-)

I don't know whether it was you.

Manu


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

Re: [linux-dvb] DVB API update

[Janne Grunau]

On Tuesday 18 September 2007 01:41:04 Manu Abraham wrote:
> Johannes Stezenbach wrote:
> > On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> >> Johannes Stezenbach wrote:
> >>>
> >>> The recording filters are exactly the piece from V4 which has the
> >>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
> >>> it's important on a PC which can copy > 1GByte/s in RAM. More
> >>> interesting would be the ability to have multiple independant
> >>> filtered TS outputs instead of just one dvr device.
> >>
> >> Currently have you tried playing back a High Bit rate H.264 stream
> >> default of a DVB-S2 stream ? I guess not.
> >>
> >> If you have had, you will see my reasons why i am trying to
> >> optimize the overheads.
> >> BTW: it is not RAM that matters here, but CPU horsepower
> >
> > A demux doesn't decode, and what matters is memory bandwidth.
>
> Try running a software decoder alongwith and tell me that that
> decoding doesn't need CPU

right the software decoder needs cpu power.

> and then the options what you can look at 
> is cutting whatever overheads it is.

Wrong, you would start optimizing parts with take significant time. I 
can record 20mbps streams on a machine capable of decoding H264 1080p 
video with more than 99 percent idle. So even if you can optimize 
capturing the stream to taking zero cpu cycles (and you can't) you will  
see at most 1% increase in decoding speed.

While having zero copy demux would be nice, it is neither relevant for 
H264 decoding nor DVB-S2.

DVB-C qam256 8mhz channels have the same bitrate as DVB-S2 transponders 
and work just fine now.

Janne

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

> Given that there already is well-discussed API enhancement
> proposal for DVB-S2, affectionately but wrongly called
> "multiproto" (MPE?), I don't know why you don't get this
> merged first instead of making that task bigger and have
> everyone wait longer for the end result?

If you had such a thought for the users you wouldn't have carried this
discussion so far like this. Why simply waste everyone's time ?


Manu


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>
>>> I really don't think there is any problem in releasing API version 3.3
>>> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
>>>
>>> And I think it would be wrong to delay DVB-S2 support until you
>>> have all of DVB-H, DVB-T2, etc. properly hammered out.
>> Johannes: why do you play this nasty thing ?
>>
>> Quoting yourself from your last mail:
>>
>> " new ioctl later for DVB-H etc. (DVB-SH, DVB-T2
>>   and DVB-C2 anyone?) "
>>
>> So who wrote about C2 and T2 (me ?)
> 
> Sigh, that was just an example. Replace it with ARIB, ASI,
> demux and statistics if it makes you happier.
>

If you see my mail, you will understand whether the experimental tree is
about ARIB or ASI. With regards to ASI i tried to help someone using ASI.


> I'm not trying to play games.
> 

Since you try to reinterpret my mails completely different, i have no
reason to think that you are doing anything else otherwise.


Manu


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007, Manu Abraham wrote:
>> Of course linuxtv.org being your private server (which you indirectly
>> said in one of the mails) doesn't mean that you can just talk whatever
>> you want
> 
> ???
> 
>> I do feel so upset talking about such things. It is such a pathetic
>> state, that the so called community is just one person, who holds the
>> remote control of controlling all the people.
> 
> ???
> 
> If this view is shared by others I will just go away.
> 
> I do feel so upset that I wasted my time trying to give
> you good advice, and not only are you not listening
> but also just throwing shit at me in return. Thanks.
> 

Why do you get upset when someone throws shit at you ? The same others
also will feel the same as well, No ?
I don't think it is a one way bridge.

Results are an outcome of efforts put in and not just simple loose talks.

Manu


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>> Johannes Stezenbach wrote:
>>
 If you would like to fix that in V3, i would much appreciate. If you
 would just like to keep talking only, maybe lets then not talk too much
 about it.
>>> The recording filters are exactly the piece from V4 which has the
>>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>>> it's important on a PC which can copy > 1GByte/s in RAM. More
>>> interesting would be the ability to have multiple independant filtered
>>> TS outputs instead of just one dvr device.
>> Currently have you tried playing back a High Bit rate H.264 stream
>> default of a DVB-S2 stream ? I guess not.
>>
>> If you have had, you will see my reasons why i am trying to optimize the
>> overheads.
>> BTW: it is not RAM that matters here, but CPU horsepower
> 
> A demux doesn't decode, and what matters is memory bandwidth.

Try running a software decoder alongwith and tell me that that decoding
doesn't need CPU and then the options what you can look at is cutting
whatever overheads it is.

Finally even memory bandwidth comes to a bottleneck at the CPU FSB. Try
capturing a High bit stream while playing along. After a while, you will
also think in the same lines of optimizations.
The problems arise when one person just talks without doing anything.
This is the root cause of all problems.

Some people call it: It's all fart and no shit (about just talking along
and doing nothing)

Manu


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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
> Johannes Stezenbach wrote:
> 
> >> If you would like to fix that in V3, i would much appreciate. If you
> >> would just like to keep talking only, maybe lets then not talk too much
> >> about it.
> > 
> > The recording filters are exactly the piece from V4 which has the
> > "mmap DMA buffers" zero copy API. But to be honest, I don't think
> > it's important on a PC which can copy > 1GByte/s in RAM. More
> > interesting would be the ability to have multiple independant filtered
> > TS outputs instead of just one dvr device.
> 
> Currently have you tried playing back a High Bit rate H.264 stream
> default of a DVB-S2 stream ? I guess not.
> 
> If you have had, you will see my reasons why i am trying to optimize the
> overheads.
> BTW: it is not RAM that matters here, but CPU horsepower

A demux doesn't decode, and what matters is memory bandwidth.

Johannes

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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Tue, Sep 18, 2007, Manu Abraham wrote:
> 
> Of course linuxtv.org being your private server (which you indirectly
> said in one of the mails) doesn't mean that you can just talk whatever
> you want

???

> I do feel so upset talking about such things. It is such a pathetic
> state, that the so called community is just one person, who holds the
> remote control of controlling all the people.

???

If this view is shared by others I will just go away.

I do feel so upset that I wasted my time trying to give
you good advice, and not only are you not listening
but also just throwing shit at me in return. Thanks.


Johannes

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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Tue, Sep 18, 2007, Manu Abraham wrote:
> Johannes Stezenbach wrote:
> 
> > I really don't think there is any problem in releasing API version 3.3
> > with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
> > 
> > And I think it would be wrong to delay DVB-S2 support until you
> > have all of DVB-H, DVB-T2, etc. properly hammered out.
> 
> Johannes: why do you play this nasty thing ?
> 
> Quoting yourself from your last mail:
> 
> " new ioctl later for DVB-H etc. (DVB-SH, DVB-T2
>   and DVB-C2 anyone?) "
> 
> So who wrote about C2 and T2 (me ?)

Sigh, that was just an example. Replace it with ARIB, ASI,
demux and statistics if it makes you happier.

I'm not trying to play games.


Johannes

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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Mon, Sep 17, 2007, Steven Toth wrote:
> Johannes Stezenbach wrote:
>>
>> But after all the discussions, and you and Steve have written
>> drivers which I hope prove the API as working, why do you
>> still think it is experimental? What would it take to make
>> it non-experimental?
>
> My take on the patches is this:
>
> It's experimental.
>
> However, it's been experimental for about a year and it's not getting 
> traction, I've said this before on the ML - it needs to be driven. I've 
> been pinging Manu recently to put up a tree on linuxtv.org/hg, merged with 
> the latest v4l-dvb tree so people like myself can start testing, breaking 
> and patching the tree.
>
> No tree = no testers = no discussion = no review = no merge = no support in 
> Linux.
>
> I want to help start the ball rolling.

Great, sounds like a good plan.

>> I wish you'd just stop with all those private discussions and instead
>> keep it on the list all the time. That way everyone would have all
>> the relevant information, which is one of the key points of doing
>> Open Source development: spreading not just the code but also the
>> knowledge about the technology. mrec isn't completely wrong when he says
>> that this list gives the appearance of a closed, elitist circle where
>> everything interesting happens in backrooms.
>
> That's a little harsh Johannes. :)

But I mean it. I used clear words so everyone would get it.

> I contacted Manu privately and offered to help him with the patch. Why? 
> Because whenever I've tried to debate or encourage this via the ML it's 
> gone nowhere. The ML is only useful to a point, then it's meaningless and 
> 1-to-1 communication is required.

Fair enough. The story behind this is that I had been Cc'd out of the
blue in a private discussion about this (even after I told Manu serveral
times that I don't want to participate in private technical
discussions), and had I not pushed for taking it to the list
then a new tree would have appeared on linuxtv, leaving many
people oblivious to it's purpose and the story behind it's creation.

It's very simple: If you want to work like that, then just
leave me out of it. There is no need to get me involved.


Johannes

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>> forever on the same thing.
> 
> Exactly, that's why I blocked your initial attempt to merge the
> DVB-S2 API extensions. *That* it was experimental code (even
> completely untested).
> 

Exactly the reason why i am hesitant to take your advice ATM, I took
your advice at that point of time, you flamed me the best you could do.

There wasn't much changes from then and now except for your "Linuxy"
statements and a pad, for which you need have made such a huge mess. Of
course i do agree that the pad was necessary, but you did not have to
make that much of a noise for the same.

Of course linuxtv.org being your private server (which you indirectly
said in one of the mails) doesn't mean that you can just talk whatever
you want

I do feel so upset talking about such things. It is such a pathetic
state, that the so called community is just one person, who holds the
remote control of controlling all the people.

HTH
Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

>> If you would like to fix that in V3, i would much appreciate. If you
>> would just like to keep talking only, maybe lets then not talk too much
>> about it.
> 
> The recording filters are exactly the piece from V4 which has the
> "mmap DMA buffers" zero copy API. But to be honest, I don't think
> it's important on a PC which can copy > 1GByte/s in RAM. More
> interesting would be the ability to have multiple independant filtered
> TS outputs instead of just one dvr device.

Currently have you tried playing back a High Bit rate H.264 stream
default of a DVB-S2 stream ? I guess not.

If you have had, you will see my reasons why i am trying to optimize the
overheads.
BTW: it is not RAM that matters here, but CPU horsepower


HTH

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

 * ARIB extensions
>>> I don't see anyone writing a driver using that, so why bother?
>>>
>> Someone asked me over IRC a few weeks back on a demod, moreover i have a
>> 13 seg tuner. (You have the sources for that driver from me, currently)
> 
> Last time I looked the ARIB specs were available in Japanese language only,
> so I assumed you wouldn't work on it.


I didn't know Japanese turned into English overnight. Btw a year and a
half back when i looked at it, it was still the same.

http://www.dibeg.org/aribstd/ARIBSTD.htm


HTH

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

>>> See? Keep it simple. Do just one thing at a time.
>> I don't see it.
> 
> I hope my explanations made it easier to see.
> Do you see it now?

I still don't see it. Did you not read my first reply to you ?


Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
>> As i said, will you take charge in fixing the demuxer
>> for complete S2 as well as other protocols ?
>> (Since you had a larger hand in the whole mess created, what i mean here
>> is that you maintained DVB for a long while)
> 
> Nice try. :-)  No I won't implement anything.
> 
> I give you my advice because I think it would make your life much
> easier and also lead to a technically better result if you would listen.
> You are of course free to ignore it.
> 
> (And it really just meant as advice, and not as
> a flame of whatever.)
> 

As usual from you (not that i expected anything better), create a flame
and then state it is an advice. Nice try.

> 
> HTH,
> Johannes
> 

HTH

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

> I really don't think there is any problem in releasing API version 3.3
> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
> 
> And I think it would be wrong to delay DVB-S2 support until you
> have all of DVB-H, DVB-T2, etc. properly hammered out.

Johannes: why do you play this nasty thing ?

Quoting yourself from your last mail:

" new ioctl later for DVB-H etc. (DVB-SH, DVB-T2
  and DVB-C2 anyone?) "

So who wrote about C2 and T2 (me ?)

What i said in reply to your statement:

" DVB.org has called for the papers currently for C2 and T2, basically the
idea they have put up is to use LDPC/BCH instead of Reed/Solomon.
Another year or 2 for DVB-C2 or T2.

But even before that i guess we need to work for the hardware which do
exist, rather than for devices the even the complete base specification
is not yet released. Don't you think so ?"

Please stop playing it to your tune, to make others look like total
idiots. Maybe you would like to give some 10 mile long explanation. I am
not going to bite into your accusations.

HTH



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

Re: [linux-dvb] DVB API update

[Steven Toth]

Johannes Stezenbach wrote:
> On Mon, Sep 17, 2007, Manu Abraham wrote:
>   
>> The problem is that, after making something experimental, throwing it
>> out to application authors stating here it is: the API update, again a
>> fix to the API will make anyone furious, nobody wants to keep tinkering
>> forever on the same thing.
>> 
>
> Exactly, that's why I blocked your initial attempt to merge the
> DVB-S2 API extensions. *That* it was experimental code (even
> completely untested).
>
> But after all the discussions, and you and Steve have written
> drivers which I hope prove the API as working, why do you
> still think it is experimental? What would it take to make
> it non-experimental?
>   

My take on the patches is this:

It's experimental.

However, it's been experimental for about a year and it's not getting 
traction, I've said this before on the ML - it needs to be driven. I've 
been pinging Manu recently to put up a tree on linuxtv.org/hg, merged 
with the latest v4l-dvb tree so people like myself can start testing, 
breaking and patching the tree.

No tree = no testers = no discussion = no review = no merge = no support 
in Linux.

I want to help start the ball rolling.

People are mailing me directly for HVR4000 support. They are offering to 
test trees and I have nothing to give them. The HVR4000 patches are 
probably nearly a year old. These people would be more than willing to 
highlight bugs, I'm more than willing to help provide patches and drive 
this patch to its natural conclusion, along with the Ack of all the 
other devs... to a merge.

<...>
> I really don't think there is any problem in releasing API version 3.3
> with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.
>
> And I think it would be wrong to delay DVB-S2 support until you
> have all of DVB-H, DVB-T2, etc. properly hammered out.
>
>   

Agreed.

> 
>   
>> Had a discussion with Steven too on this, since he has a driver as well.
>> Why this is experimental ? I guess you get all the answers from within
>> this mail itself.
>> 
>
> I wish you'd just stop with all those private discussions and instead
> keep it on the list all the time. That way everyone would have all
> the relevant information, which is one of the key points of doing
> Open Source development: spreading not just the code but also the
> knowledge about the technology. mrec isn't completely wrong when he says
> that this list gives the appearance of a closed, elitist circle where
> everything interesting happens in backrooms.
>
>   

That's a little harsh Johannes. :)

I contacted Manu privately and offered to help him with the patch. Why? 
Because whenever I've tried to debate or encourage this via the ML it's 
gone nowhere. The ML is only useful to a point, then it's meaningless 
and 1-to-1 communication is required.

However, I take your point, I suspect testing, patching and judgement 
from the apps guys will likely occur via this ML.

- Steve



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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Mon, Sep 17, 2007, Manu Abraham wrote:
> 
> The problem is that, after making something experimental, throwing it
> out to application authors stating here it is: the API update, again a
> fix to the API will make anyone furious, nobody wants to keep tinkering
> forever on the same thing.

Exactly, that's why I blocked your initial attempt to merge the
DVB-S2 API extensions. *That* it was experimental code (even
completely untested).

But after all the discussions, and you and Steve have written
drivers which I hope prove the API as working, why do you
still think it is experimental? What would it take to make
it non-experimental?

> I would prefer to say mark it experimental in
> a tree dedicated to it, such that it is explicitly stated that it is not
> a permanent solution and in the background, the fixes required for the
> relevant can be done.

IMHO application developers hate temporary APIs -- it means they
have to rewrite their code later, and there are zero guarantees
as to when you make the change to the "real" API and how big the
required changes would be.

> Don't you think so ? If someone asked me to keep working on with changes
> every now and then i wouldn't be very happy, but if i were explicitly
> told, look this is what as far what it stands as of now, it is expected
> to change, for further support, that i could digest it a bit. Trying to
> put myself into someone else's shoes.

The magic word is "backward compatibility" -- as long as that is
guaranteed, everyone _loves_ small incremental updates. They are
much easier to handle than the one large mega update which
changes the complete API.

I really don't think there is any problem in releasing API version 3.3
with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc.

And I think it would be wrong to delay DVB-S2 support until you
have all of DVB-H, DVB-T2, etc. properly hammered out.


> That said there are newer devices taking advantage of the full specs. As
> we have seen as soon as there are devices, there are applications as
> well. Vendors don't spend their funds on something nonsense and that too
> a major chunk of it. Of course there are cases, but in this case i
> highly doubt your claim.

I have no idea what you want to say with this. Missing context?

> > IIRC my closing words in the DVB-S2 API discussion were
> > along the line of "we shouldn't merge an API without users
> > into mainline now, we should wait until the first driver which
> > uses it is ready and merge both at the same time".
> > That is because a) we generally shouldn't add APIs without
> > users, b) we shouldn't add APIs which are untested and
> > thus not proven to work.
> 
> IIRC, You only wrote sometime earlier, why work on something useless
> such as DVB-S2. Why a change of thought ?

You remember wrong, I never said this.

What I said was that _at the time_ you wanted to merge your initial
API proposal, there was no DVB-S2 equipment available in stores,
and also no DVB-S2 transponder in operation. So your desire to
get this merged _then_ was premature.

> > Ever since, everyone's just been waiting for your
> > "I'm ready with my driver, please merge" mail.
> 
> I would be going on with an experimental tree after Wednesday.
> 
> Still some more things to be polished in that CCM only case too. See the
> first few posts on this DVB API update thread, The way the current API
> is, well it is as good as no statistics, but just for kids play there
> are some numbers scrolling up and down, ie the statistics do not hold
> any value. Displaying some random numbers is not statistics.

I have no idea what CCM is. If during the implementation of your
DVB-S2 driver you found that the API still needs work, then why
not just fix it -- that was the whole purpose of the exercise.

The statistics thing is independant of DVB-S2, again I see
no reason why to make the "merge DVB-S2" task bigger by
dragging this into the picture.

> Had a discussion with Steven too on this, since he has a driver as well.
> Why this is experimental ? I guess you get all the answers from within
> this mail itself.

I wish you'd just stop with all those private discussions and instead
keep it on the list all the time. That way everyone would have all
the relevant information, which is one of the key points of doing
Open Source development: spreading not just the code but also the
knowledge about the technology. mrec isn't completely wrong when he says
that this list gives the appearance of a closed, elitist circle where
everything interesting happens in backrooms.

> Sometime back you were the person who was against merging the same, now
> that you seem to suddenly pull in all that you said crap a few mails
> back. Wow, what a contradiction in statements.

See above. If by "crap a few mails back" you mean the private
discussion about this you tried to drag me into, I'm sorry but
I will block any attempts by you (and others) to discuss important
technical stuff in private. I'm very

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

On Mon, Sep 17, 2007 at 06:02:50PM +0200, Johannes Stezenbach wrote:
> On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
> > 
> > - dvb_fe_type: DVB-S2 is missing and I personally would also like
> >   to see ASI here...
> 
> See my other mail, IMHO we should add the ASI defines at
> the same time we merge a driver which uses it.

Well, on the other hand this can prevent from others (hardware
vendors?) to have a deeper look into the linux-dvb api because
it does not even care about ASI.

Again, I think the "dummy" frontend approach from Manu could be a
viable solution, but you should have the possibility to add a basic
frontend with minimal status information (lock/no lock) without
much headache.

> > - frontend status:
> >   - BER is lacking a proper definition (to which base is it calculated?)
> >   - signal strength: same problem, what are the ranges?
> >   - snr: again, no base and ranges given
> 
> The original Nokia DVB API spec had proper definitions, but
> Holger Waechtler and me decided to drop them in favour of
> "read hw register and scale to range 0..0x". The reasons
> for this were:
> - for some hw we didn't have info to implement it properly
> - for those hw where we had info we saw it wasn't worth the
>   effort -- I believe the implementation in the demod firmware
>   is just such a coarse approximation that it doesn't
>   even make a difference if you take the logarithm or not
>   (provided you scale back into the 16bit range)
>   (of course you get different numbers, but none of them
>   maps any better to what you'd expect)
[...]

I do not have info about much hardware, all I can say is that
BER and SNR work quite good with STV0299, STV0288, TDA10046 and
TDA1002x. This is reason enough for me to raise the hand for
voting for an interface that at least gives the possibility
to implement this in the demod driver.
(I have to admit that you have to use some basic averaging, but
if this could be handled in some kind of frontend thread, I see
no problem. I will see how this can be implemented without floating
point calculation, because up to now this was done on another
platform where floating point was not an issue.)

The main reason to do this is because this is the only place
where it _can_ be done! The application accesses the demod through
the API and does not know anything about its registers or anything,
neither should it.

BTW, the "scale to range 0..0x" does not seem to be true for
all demods (at least this is what I remember), and at the very least,
this scale and direction (0 = best or worst?) should be clearly
stated in the API!

>From my point of view and taking into account your arguments, the
main problem is: how could one implement such an interface in a
backward-compatible manner and such that an application can see
if the demod it currently uses does return precise values (that
can be displayed as dB or something like that) or not, because
there may be demods where we really can not provide proper values
or that simply nobody had the time to look at yet.

Best regards,
Wolfgang


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

> I think this API sucks. DVB API V1 had a "read/write demod register"
> ioctl for debugging, which was removed because you could also use
> i2c-dev. It would be better to find a way to use i2c-dev with
> proper locking wrt fe->sem than to cram arbitrary and probably
> unspecified hw data with unversioned layout into the DVB API.

Sounds broken. What about non-I2C devices ?


Manu


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> On Sun, Sep 16, 2007, Rainer.scherg wrote:
>>   - A runtime version check of the API is needed. Currently the API
>> version is determined at compile time, which is useless, when
> 
> It is necessary in the same way as you have KERNEL_VERSION
> or GLIB_MAJOR_VERSION etc.

I guess only you think that way. LK folks seem to think otherwise, that
the current versioning is evil.

HTH


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:

> 
> Someone once told me: Marketing requirement is that the
> signal quality bar is in the upper third when the picture
> is good, and in the lower third when the picture is bad.
> Everthing else is irrelevant and the numbers can be pure fantasy.
> And that's what I believe you get from most demods, and how
> it is implemented in most commercial receivers.

Wrong.

See my initial reply to Wolfgang on the start of this thread. It is not
crappy hardware, but the way the drivers were written, but in any case
the drivers couldn't be made better, because the API enforced someone's
view that it was that.

In fact it was the view that was crappy nothing else.


HTH

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Johannes Stezenbach wrote:
> Hi Manu,
> 
> On Sat, Sep 15, 2007, Manu Abraham wrote:
>> While being on the V3 frontend API overhaul, i found to much dismay that
>> it would be much better to revamp V4 into a newer API version such as
>> V5, rather than scratching with V3 for ages together, resulting in just
>> unnecessary talks and discussions.
> 
> It is beyond me why you think creating a new API would
> result in less "unnecessary" discussions that improving
> the existing API... :-)

(Oh, here comes the flame thrower from Johannes with a smiley)

With regards to improving the existing API, just see the past reactions
and too many unnecessary discussions. It is too much work to get going
with a running API. It is next to impossible with all those politics in.

To make it simpler, the existing API is a bit broken too much. :)

> Given that there already is well-discussed API enhancement
> proposal for DVB-S2, affectionately but wrongly called
> "multiproto" (MPE?), I don't know why you don't get this
> merged first instead of making that task bigger and have
> everyone wait longer for the end result?

multiproto "did not" mean Multi Protocol Encapsulation, but just meant
multiple delivery systems. The original naming carried on from the first
patch. IIRC, it was Obi who said/(corrected) that it would be incorrect
to term protocol and hence changed to delivery system, but the naming
just stuck to it, that's all.

(Confusion again) i wonder how we can get rid of all these confusion
between people. ;-)

You see why now, rather being affection ?

The problem is that, after making something experimental, throwing it
out to application authors stating here it is: the API update, again a
fix to the API will make anyone furious, nobody wants to keep tinkering
forever on the same thing. I would prefer to say mark it experimental in
a tree dedicated to it, such that it is explicitly stated that it is not
a permanent solution and in the background, the fixes required for the
relevant can be done.

Don't you think so ? If someone asked me to keep working on with changes
every now and then i wouldn't be very happy, but if i were explicitly
told, look this is what as far what it stands as of now, it is expected
to change, for further support, that i could digest it a bit. Trying to
put myself into someone else's shoes.

That said there are newer devices taking advantage of the full specs. As
we have seen as soon as there are devices, there are applications as
well. Vendors don't spend their funds on something nonsense and that too
a major chunk of it. Of course there are cases, but in this case i
highly doubt your claim.

Not making others wait longer, see down..

> IIRC my closing words in the DVB-S2 API discussion were
> along the line of "we shouldn't merge an API without users
> into mainline now, we should wait until the first driver which
> uses it is ready and merge both at the same time".
> That is because a) we generally shouldn't add APIs without
> users, b) we shouldn't add APIs which are untested and
> thus not proven to work.

IIRC, You only wrote sometime earlier, why work on something useless
such as DVB-S2. Why a change of thought ?

:)

> Ever since, everyone's just been waiting for your
> "I'm ready with my driver, please merge" mail.

I would be going on with an experimental tree after Wednesday.

Still some more things to be polished in that CCM only case too. See the
first few posts on this DVB API update thread, The way the current API
is, well it is as good as no statistics, but just for kids play there
are some numbers scrolling up and down, ie the statistics do not hold
any value. Displaying some random numbers is not statistics.

Had a discussion with Steven too on this, since he has a driver as well.
Why this is experimental ? I guess you get all the answers from within
this mail itself.

Sometime back you were the person who was against merging the same, now
that you seem to suddenly pull in all that you said crap a few mails
back. Wow, what a contradiction in statements.

I would like to see the other features of DVB-S2 go in as well, since
there are newer devices using those features. But for that i wouldn't
prefer to work with the V3 demuxer, but prefer to go with V4 which has
the advantages of ZeroCopy at least.

>> What i find interesting with the V4 API
>> * A better demuxer
> 
> But it's also overcomplicated and like MiHu explained not
> targeted at PCI/USB cards. IMHO It would be useful to add
> a simple version of the recording filters to the V3 demux.

Copying around, i would like to avoid. With High bitrate streams etc,
for HD streams the PC would be already saturated, i would like to cut
down whatever unnecessary overheads that do exist.

If you would like to fix that in V3, i would much appreciate. If you
would just like to keep talking only, maybe lets then not talk too much
about it.

>> * ARIB extensions
> 
> I don't see anyone writing a driver using that, so why bother?
>

S

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Sat, Sep 15, 2007, Wolfgang Wegner wrote:
> 
> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>   to see ASI here...

See my other mail, IMHO we should add the ASI defines at
the same time we merge a driver which uses it.

> - frontend status:
>   - BER is lacking a proper definition (to which base is it calculated?)
>   - signal strength: same problem, what are the ranges?
>   - snr: again, no base and ranges given

The original Nokia DVB API spec had proper definitions, but
Holger Waechtler and me decided to drop them in favour of
"read hw register and scale to range 0..0x". The reasons
for this were:
- for some hw we didn't have info to implement it properly
- for those hw where we had info we saw it wasn't worth the
  effort -- I believe the implementation in the demod firmware
  is just such a coarse approximation that it doesn't
  even make a difference if you take the logarithm or not
  (provided you scale back into the 16bit range)
  (of course you get different numbers, but none of them
  maps any better to what you'd expect)

Someone once told me: Marketing requirement is that the
signal quality bar is in the upper third when the picture
is good, and in the lower third when the picture is bad.
Everthing else is irrelevant and the numbers can be pure fantasy.
And that's what I believe you get from most demods, and how
it is implemented in most commercial receivers.
But, well, that was a few years back and it was crappy hw, maybe
the situation improved.

I'm not opposed to it if you want to improve the situation,
but IMHO you shouldn't put your expectations too high...


HTH,
Johannes

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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

On Sun, Sep 16, 2007, Rainer.scherg wrote:
> 
>   - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when

It is necessary in the same way as you have KERNEL_VERSION
or GLIB_MAJOR_VERSION etc.

> distributing binaries (one of the bad things on linux are
> incompatible API changes over time).
> A simple major.minor version number check will IMO do.

We dicided against it since a capabilities based interface
is much nicer to use. Or a simple "try new ioctl, if that
returns ENOTTY use old ioctl" approach...

>   - a "user structure" for hardware specific data (e.g. retrieve
> special data from a special frontend chip would be nice.
> this should be optional (*NULL = not used or not implemented).
> otherwise something like:
>struct { char[xx]   hw_info;
> specific data...
> }  *;

I think this API sucks. DVB API V1 had a "read/write demod register"
ioctl for debugging, which was removed because you could also use
i2c-dev. It would be better to find a way to use i2c-dev with
proper locking wrt fe->sem than to cram arbitrary and probably
unspecified hw data with unversioned layout into the DVB API.

>   - API 3 is missing a a function for retrieving current frontend
> settings (e.g. on SAT  LNB settings). It would be sufficient, when
> simply the last parameters set are returned.
> Currently on API3 a "second dvb application" can change the frontend,
> whithout any chance for the "main dvb application" to detect this
> easily.

As already outlined by Manu it doesn't work. DiSEqC command
strings can be of arbitrary length, we don't buffer this in the driver.


Johannes

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

Re: [linux-dvb] DVB API update

[Johannes Stezenbach]

Hi Manu,

On Sat, Sep 15, 2007, Manu Abraham wrote:
> 
> While being on the V3 frontend API overhaul, i found to much dismay that
> it would be much better to revamp V4 into a newer API version such as
> V5, rather than scratching with V3 for ages together, resulting in just
> unnecessary talks and discussions.

It is beyond me why you think creating a new API would
result in less "unnecessary" discussions that improving
the existing API... :-)

Given that there already is well-discussed API enhancement
proposal for DVB-S2, affectionately but wrongly called
"multiproto" (MPE?), I don't know why you don't get this
merged first instead of making that task bigger and have
everyone wait longer for the end result?

IIRC my closing words in the DVB-S2 API discussion were
along the line of "we shouldn't merge an API without users
into mainline now, we should wait until the first driver which
uses it is ready and merge both at the same time".
That is because a) we generally shouldn't add APIs without
users, b) we shouldn't add APIs which are untested and
thus not proven to work.

Ever since, everyone's just been waiting for your
"I'm ready with my driver, please merge" mail.


> What i find interesting with the V4 API
> * A better demuxer

But it's also overcomplicated and like MiHu explained not
targeted at PCI/USB cards. IMHO It would be useful to add
a simple version of the recording filters to the V3 demux.


> * ARIB extensions

I don't see anyone writing a driver using that, so why bother?


Given that we always need to stay backward compatible with
old API versions, I believe it is much easier to improve
the existing API in small incremental steps than to introduce
a completely new API. (While working on V4, we were always
thinking "hey, we can add backward compat later", but frankly
I don't see how this could've worked out.)


For DVB-S2 the problem was:
- couldn't extend FE_SET_FRONTEND without breaking
  backwards compat
- thus need new ioctl
- to not repeat the same mistake I proposed to add
  "forward compatibility" so we could extend the
  new ioctl later for DVB-H etc. (DVB-SH, DVB-T2
  and DVB-C2 anyone?)
  (V4L2 API does the same thing)

See? Keep it simple. Do just one thing at a time.


HTH,
Johannes

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Wolfgang Wegner wrote:
> On Mon, Sep 17, 2007 at 03:38:12PM +0400, Manu Abraham wrote:
>> Right.
>>
>> Do you think we can generalize it to a DUMMY frontend where some fields
>> are just queried ?
>>
>> If so it would be a matter of just defining a "dummy name" for the
>> general category of headless devices where some statistics can be
>> queried. Or do you think it would be right to have it called as DVB-ASI
>> frontend itself ?
>>
>> (In my thoughts it would be incorrect probably to call it DVB-ASI, since
>> DVB-ASI doesn't get specified as a delivery system as defined by a
>> frontend, but just as a transport method only)
>>
>> But in that case each of those headless devices will need to have a
>> specific name. Though not too many headless devices come to my mind though.
> 
> Right, at the moment I can only think of the parallel (LVDS) interface
> and ASI, where the ASI "frontend" might have some more capabilities due
> to the encapsulation.
> 
> Apart from that, i am totally fine with the dummy approach. And, as you
> mentioned, it is more in-line with the delivery system definition.

Ok, something like this would help ?

Regards,
Manu

/*
 * Capability bit field for DVB-ASI
 * References:
 * Cenelec EN 50083-9
 */
enum dvbfe_dvbasi_transmission {
DVBFE_DVBASI_SERIAL = (1 << 31),
DVBFE_DVBASI_PARALLEL   = (1 << 30)
};

struct dvbfe_dvbasi_info {
enum dvbfe_asi_transmission transmission;

__u8pad[32];
};

/* DVB Frontend related Information */
struct dvbfe_info {
charname[128];

/* For Multi Standard tuners, set "delivery"
 * to the relevant delivery system to retrieve the
 * relevant delivery system related information.
 */
enum dvbfe_delsys   delivery;

union {
struct dvbfe_dvbs_info  dvbs;
struct dvbfe_dss_info   dss;
struct dvbfe_dvbs2_info dvbs2;
struct dvbfe_dvbc_info  dvbc;
struct dvbfe_dvbt_info  dvbt;
struct dvbfe_dvbh_info  dvbh;
struct dvbfe_atsc_info  atsc;
struct dvbfe_dvbasi_infoasi;

__u8pad[128];
} delsys;

__u32   frequency_min;
__u32   frequency_max;
__u32   frequency_step;
__u32   frequency_tolerance;
__u32   symbol_rate_min;
__u32   symbol_rate_max;
__u32   symbol_rate_tolerance;

enum fe_spectral_inversion  inversion;

__u8pad[128];
};
#define DVBFE_GET_INFO  _IOWR('o', 85, struct dvbfe_info)


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

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

On Mon, Sep 17, 2007 at 03:38:12PM +0400, Manu Abraham wrote:
> 
> Right.
> 
> Do you think we can generalize it to a DUMMY frontend where some fields
> are just queried ?
> 
> If so it would be a matter of just defining a "dummy name" for the
> general category of headless devices where some statistics can be
> queried. Or do you think it would be right to have it called as DVB-ASI
> frontend itself ?
> 
> (In my thoughts it would be incorrect probably to call it DVB-ASI, since
> DVB-ASI doesn't get specified as a delivery system as defined by a
> frontend, but just as a transport method only)
> 
> But in that case each of those headless devices will need to have a
> specific name. Though not too many headless devices come to my mind though.

Right, at the moment I can only think of the parallel (LVDS) interface
and ASI, where the ASI "frontend" might have some more capabilities due
to the encapsulation.

Apart from that, i am totally fine with the dummy approach. And, as you
mentioned, it is more in-line with the delivery system definition.

Regards,
Wolfgang


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Wolfgang Wegner wrote:
> On Mon, Sep 17, 2007 at 02:57:32PM +0400, Manu Abraham wrote:
>> CityK wrote:
>>> Its described in:
>>>  
>>> "/EN 50083-9:2002 : //Cable networks for television signals, sound
>>> signals and interactive services. Part 9: Interfaces for CATV/SMATV
>>> head-ends and similar professional equipment for DVB/MPEG2 transport
>>> streams. "
>> Cool. Thanks for the info. (Sounds like cityk has been crawling all over
>> the net :-) )
>> Another Cenelec spec... :-|
> 
> Cityk, thanks for the info!
> 
> Manu, I can understand your argument that there should not be something
> integrated that is based on guesswork, but I think it is not that bad.
> 
> The basic parameters needed for "tuning" or querying the status should
> be easy to define - wether a specific "frontend" supports all these or
> not would have to be queried via capabilities anyways, IMHO.

Right.

Do you think we can generalize it to a DUMMY frontend where some fields
are just queried ?

If so it would be a matter of just defining a "dummy name" for the
general category of headless devices where some statistics can be
queried. Or do you think it would be right to have it called as DVB-ASI
frontend itself ?

(In my thoughts it would be incorrect probably to call it DVB-ASI, since
DVB-ASI doesn't get specified as a delivery system as defined by a
frontend, but just as a transport method only)

But in that case each of those headless devices will need to have a
specific name. Though not too many headless devices come to my mind though.

Regards,
Manu

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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi Wolfgang,

Wolfgang Wegner wrote:
> Hi Manu,
> 
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
>> Please don't remove the CC's. The CC'd people generally don't bother
>> about mails from the ML, probably.
> 
> sorry, it was definitely not my intention and I hope to include
> all previous CC here.
> 
> [have to read about the multiproto changes myself...]
> 
>> Can you please point me to some ASI specs if you don't mind ?  I was
>> once supposed to work on such a device, but then that company itself got
>> scrapped, hence never had to figure out on ASI.
> 
> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other boards,
> at least some basic support for ASI seems to be desirable.
> 
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode


>From what i understood from the specs, only BER would be a criteria that
would match as a relevant candidate for the frontend. With regards to
the frontend what we mean by SYNC is Viterbi Sync.

With regards to ASI, there isn't any Viterbi decoder but just a 8B/10B
decoder as found in some NIC's

The 204/188 packet size would be a better candidate for the demuxer as
far as i can think, but this the user need not intervene (similar to
current DMA implementations on the PCI DVB cards we have)

This is the basic idea that i got after going through the specs.

Basically, i think an ASI device implementation should be quite simple,
"maybe" even a dummy frontend would do, if not for the BER statistics.

Maybe Ralph can chime in his inputs to this as he has worked with an ASI
device at some point of time.

Regards,
Manu

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

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

On Mon, Sep 17, 2007 at 02:57:32PM +0400, Manu Abraham wrote:
> CityK wrote:
> > Its described in:
> >  
> > "/EN 50083-9:2002 : //Cable networks for television signals, sound
> > signals and interactive services. Part 9: Interfaces for CATV/SMATV
> > head-ends and similar professional equipment for DVB/MPEG2 transport
> > streams. "
> 
> Cool. Thanks for the info. (Sounds like cityk has been crawling all over
> the net :-) )
> Another Cenelec spec... :-|

Cityk, thanks for the info!

Manu, I can understand your argument that there should not be something
integrated that is based on guesswork, but I think it is not that bad.

The basic parameters needed for "tuning" or querying the status should
be easy to define - wether a specific "frontend" supports all these or
not would have to be queried via capabilities anyways, IMHO.

Regards,
Wolfgang


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

CityK wrote:
> Wolfgang Wegner wrote:
> 
>> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>>   to see ASI here...
>>   
> Its described in:
>  
> "/EN 50083-9:2002 : //Cable networks for television signals, sound
> signals and interactive services. Part 9: Interfaces for CATV/SMATV
> head-ends and similar professional equipment for DVB/MPEG2 transport
> streams. "


Cool. Thanks for the info. (Sounds like cityk has been crawling all over
the net :-) )
Another Cenelec spec... :-|

(I guess it is always that when you think, that when you don't want to
deal with something later on again, there you get to deal with that
again ..)

Thanks,
Manu

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

Re: [linux-dvb] DVB API update

[CityK]

CityK wrote:
> Its described in:
>  
> "/EN 50083-9:2002 : //Cable networks for television signals, sound
> signals and interactive services. Part 9: Interfaces for CATV/SMATV
> head-ends and similar professional equipment for DVB/MPEG2 transport
> streams. "
> /
>
> //which is available (if you're registered) from:
> http://www.cenelec.org/Cenelec/Code/Frameset.aspx
> //
>
> ///
> /
>
> /
> /
>
> /
> /

Apparently Thunderbird didn't like that copy & paste of the title:

EN 50083-9:2002 : Cable networks for television signals, sound
signals and interactive services. Part 9: Interfaces for CATV/SMATV
head-ends and similar professional equipment for DVB/MPEG2 transport
streams 



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

Re: [linux-dvb] DVB API update

[CityK]

Wolfgang Wegner wrote:

> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>   to see ASI here...
>   

Manu Abraham wrote:
> Can you please point me to some ASI specs if you don't mind ?  I was
> once supposed to work on such a device, but then that company itself got
> scrapped, hence never had to figure out on ASI.

Wolfgang Wegner wrote:

> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other boards,
> at least some basic support for ASI seems to be desirable.
>
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode
>   

Its described in:
 
"/EN 50083-9:2002 : //Cable networks for television signals, sound
signals and interactive services. Part 9: Interfaces for CATV/SMATV
head-ends and similar professional equipment for DVB/MPEG2 transport
streams. "
/

//which is available (if you're registered) from:
http://www.cenelec.org/Cenelec/Code/Frameset.aspx
//

///
/

/
/

/
/



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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi Wolfgang,

Wolfgang Wegner wrote:
> Hi Manu,
> 
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
>> Please don't remove the CC's. The CC'd people generally don't bother
>> about mails from the ML, probably.
> 
> sorry, it was definitely not my intention and I hope to include
> all previous CC here.
> 

np. :)

> [have to read about the multiproto changes myself...]

You can find the last update over here:
http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2
It is in fact a complete tree which is encapsulated in a tarball, just
because i had been in the other OS, at that point of time.

>> Can you please point me to some ASI specs if you don't mind ?  I was
>> once supposed to work on such a device, but then that company itself got
>> scrapped, hence never had to figure out on ASI.
> 
> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other boards,
> at least some basic support for ASI seems to be desirable.
> 
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode

I will try to collect whatever info i can, as well before we jump into a
wrong conclusion. The more info we have, the better it is.

It would be incorrect to add in to an API based much on guess work,
unless we have real scenarios, once into an API it is there forever, so
we have to be much cautious about it. If it is wrong, the only other
option later, even if you have real information would be workarounds.


> 
> [...]
>> Since it is an IOCTL call straight away within the V3 API, i would like
>> to push this into the frontend thread where it is submitted as a job
>> kind of thing, where the userapplication can be notified in what
>> timeframe, or via GET_EVENTS, final details can be left out for the last
>> stage.
> 
> This sounds very reasonable for me. I have no idea yet how this frontend
> thread is handled now, but after all all necessary information should be
> present there (e.g. lock state, to do a proper reset of averaging etc.).

Currently it is used only for tuning , ie frontend setup. In the case of
the dvb-s2 (stb0899) driver, i have implemented the search algorithm
from the frontend thread, instead of a blind setting up of parameters


>> Scale for BER is one thing that is still open ended, which i am off
>> hook. I need to still check on this, but if you have some ideas would be
>> nice.
> 
> Hmm... I am not sure what is needed by others, so my voice should not
> be given too much weight here. We always use 10^-8 as the base, but for
> some equipment this might already be too rough. On the other hand, IIRC
> some demodulators do not return more accurate values anyways.
> 
>> Signal Strength & SNR:
>>
>> In reality we can provide 2 ways for the same,
>> 1) Relative scale
>> 2) a scale in a decibels
>>
>> Even with Reverse Engineered drivers we can do 1) but for 2) we might
>> need more info. The user could probably select what he needs using an
>> IOCTL, relative or an absolute scale. For the relative one we can just
>> define a floor and ceiling and a relative value is extracted out.
> 
> That is what I was thinking of, for most applications this would be
> sufficient. I do not know what is the better solution here. Following
> your proposal of two different styles of return values makes life easier
> for the application (which could request the "scale" type and just take
> this value). Even knowing the exact decibel value would make it necessary
> to interpret it differently for different transmission schemes, i.e. 8 dB
> SNR in DVB-S is no problem while there would be no reception in DVB-C...
> On the other hand it might be confusing to get different values for the
> same thing, which I treat as an argument for my proposal of always (if
> possible) returning the dB value and giving the application (and user)
> the demod min and max values for drawing a nice percentage scale.
> 
> For a few demods I could provide the dB calculation (namely STV0299,
> STV0288, TDA10046, TDA1002x), but probably these are those with
> fewest problems anyways.
> For others (e.g. STV0297) there seems to be no calculation possible,
> I know of other implementations using a look-up-table. If needed, I
> could do some measurements and see if we manage to get good results
> with a look-up-table, too.

That would be great, Did a quick check on some of them:

All STM (299, 288, 899, 900) does 10^7 exception STV0297
Philips (10021, 23) does 10^5
Conexant varies from chip to chip
CX22702 says 127 bits max
CX24116 does a table lookup in the driver
Samsung S5H1409 does 10^4

On the STV0297 you need to calculate from BERT_0 and BERT_1 (0xe4 and 0xe5)
Though it 

Re: [linux-dvb] DVB API update

[Manu Abraham]

Rainer.scherg wrote:
> Manu Abraham schrieb:
> 
>>>   - a "user structure" for hardware specific data (e.g. retrieve
>>> special data from a special frontend chip would be nice.
>>> this should be optional (*NULL = not used or not implemented).
>>> otherwise something like:
>>>struct { char[xx]   hw_info;
>>> specific data...
>>> }  *;
>>>
>> Sounds good. In a tangent thought, in many cases when a special chip is
>> used sometimes there is an overall change in the hardware design.
>>
>> In such a case, do you think, that if we abstract such an info, out as a
>> part of as a new object such as an adapter object, (such that more
>> information can be passed out clearly) would be a better approach,
>> rather than shoving everything we have into the frontend object ? (where
>> the adapter object becomes the parent object for all others)
>>
>> Though i must say, that the frontend specific should be in the frontend,
>> but the adapter object could get the frontend specific information as a
>> part of it's own and present to the application. Though, you will be
>> able to query the frontend related information alone also, for carrying
>> around shorter chunks of data if the user wants to have only a small
>> subset of the information.
> 
> I did not made any deeper thoughts on how this could be implemented 
> best. What was the reason of this idea:
>A university asked me some times ago, to enhance dvbsnoop to output
>more detailled error reporting data than SIG, SNR, BER, UBLCK for
>a specific frontend (DIBCOM3000).
> 
> In this case it was related to the frontend. As you stated, a special
> object might be more useful and more flexible.


What i was thinking was the adapter as a parent retrieving information
from all the child objects.

The parent as a whole representing the adapter having very little info
about itself, the rest being composed out of various entities which are
being assembled together to form a one single chunk of data.

This also fills in the gap when different vendors are used (in most
cases) to comprise a global entity such as a card alone. You can think
of the current card config struct as a starting point, but just that it
is made a bit more effective when components from different vendors are
pulled in together to make a device, which brings in additional
constraints, which is not explicitly expressed by any of the vendors.

For a reference device this criteria does not apply, as all the
components are specified  and in most cases tested and benchmarked on
Lab equipment.

The card manufacturer being clueless on that aspect. (What they do: take
a reference device, just like how people cut and paste code, cut and
paste happens in the schematic editor, which is the entry point for a
deviation from the Reference designs. Of course some designs which are
derivatives of the reference design are better than the reference design
themselves)

For example we have limits for each device (component would be right
term), but with each possible configuration, the actual limits posed are
different, which require the information from all the components put
together (eg: demod + tuner limits are hard to express unless it is
represented by a configuration, which handles the same. Also, i think it
might better to be represented as a global representation of the adapter
rather than a frontend.)

ie. IOW, the adapter is a representation of the final component
assembly, to put things very short.

As an example, on some of the cards that i do have, i have a discrete
GaAsFET stage in front of the frontend, which does shape and provide
some amount of gain to the frontend. This is an alteration to the actual
specifications of the devices that we look at in our drivers, which also
needs to be accounted, if we are looking at more precise information.

>>
>>>   - API 3 is missing a a function for retrieving current frontend
>>> settings (e.g. on SAT  LNB settings). It would be sufficient, when
>>> simply the last parameters set are returned.
>>> Currently on API3 a "second dvb application" can change the frontend,
>>> whithout any chance for the "main dvb application" to detect this
>>> easily.
>> the dvb-core saving away the last successful LOCK state, will this help
>> ? But in any case, the second application if it successfully lock's,
>> then this would change logically, since this becomes the
>> previous-previous successful locked state.
>>
>> Is that what you meant, guess i didn't follow you correctly.
> 
> Following scenario (SAT):
>Application 1 tunes device 2:
>   to freq  1234.567 MHz, V, HiBand, SAT "2", etc..
>Application 2 tunes device 2:
>   to freq  1000.123 MHz, H, LoBand, SAT "1", etc..
> 
>   Currently application 1 has no chance to query the current
>   frontend settings.
> 
>   In a first step, a simple "query current frontend
>   settings" (last set data) for a device would be sufficient.
>   In a s

Re: [linux-dvb] DVB API update

[Rainer.scherg]

Marcel Siegert schrieb:

>>> Is that what you meant, guess i didn't follow you correctly.
>> Following scenario (SAT):
>>Application 1 tunes device 2:
>>   to freq  1234.567 MHz, V, HiBand, SAT "2", etc..
>>Application 2 tunes device 2:
>>   to freq  1000.123 MHz, H, LoBand, SAT "1", etc..
>>
>>   Currently application 1 has no chance to query the current
>>   frontend settings.
> 
> from my pov it would not be allowed to have application 2 tune to a different
> transponder if application 1 still uses it.
> 
> and, where is the deep sense in this situation?
> app 1 tunes to 1234
> 
> app 2 tunes to 1000... and therefore destroys app 1`s data
> 
> app 1 checks periodically (via get current tuning param), 
> if everything still is fine,
> the result is this case is no, so app 1 would maybe 
> try to retune to 1234-- and app2 would check and try to retune to 100
> 
> i cant see sense in your example at all. 
> 
> where i can see the sense is, to query a frontend to get back the actual 
> frontend settings, 
> but your example has a totally different problem.
> 
> 
>>   In a first step, a simple "query current frontend
>>   settings" (last set data) for a device would be sufficient.
>>   In a second step (future APIs), one could think about notification
>>   by event handlers.
> 
> which notification? a userspace application should free a frontends usage, if 
> is no longer
> using it. am i wrong?
>  
>>   I also would ignore the LOCK state and always save/return the last
>>   set parameters.
> what do you mean with ignoring a LOCK state? also return frontend settings, 
> if no LOCK
> has been done on those? if that is your point, i am ok for that.
> 
> 
> regards
> marcel
> 
> 

maybe the example was unlucky, but it should show the current problem.
It's just about querying some simple data.
There is no discussion about any application or its behavior.

So let's simplify the example:
   take a shell/perl script with 2 forked, async. processes:
 process 1 is just tuning (a) satellite(s) in steps (dvbtune).
 process 2 is frequently querying the tuned data
  and e.g. plots a diagram.


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

Re: [linux-dvb] DVB API update

[Rainer.scherg]

Manu Abraham schrieb:

> 
>>   - a "user structure" for hardware specific data (e.g. retrieve
>> special data from a special frontend chip would be nice.
>> this should be optional (*NULL = not used or not implemented).
>> otherwise something like:
>>struct { char[xx]   hw_info;
>> specific data...
>> }  *;
>>
> 
> Sounds good. In a tangent thought, in many cases when a special chip is
> used sometimes there is an overall change in the hardware design.
> 
> In such a case, do you think, that if we abstract such an info, out as a
> part of as a new object such as an adapter object, (such that more
> information can be passed out clearly) would be a better approach,
> rather than shoving everything we have into the frontend object ? (where
> the adapter object becomes the parent object for all others)
> 
> Though i must say, that the frontend specific should be in the frontend,
> but the adapter object could get the frontend specific information as a
> part of it's own and present to the application. Though, you will be
> able to query the frontend related information alone also, for carrying
> around shorter chunks of data if the user wants to have only a small
> subset of the information.

I did not made any deeper thoughts on how this could be implemented 
best. What was the reason of this idea:
   A university asked me some times ago, to enhance dvbsnoop to output
   more detailled error reporting data than SIG, SNR, BER, UBLCK for
   a specific frontend (DIBCOM3000).

In this case it was related to the frontend. As you stated, a special
object might be more useful and more flexible.


> 
> 
>>   - API 3 is missing a a function for retrieving current frontend
>> settings (e.g. on SAT  LNB settings). It would be sufficient, when
>> simply the last parameters set are returned.
>> Currently on API3 a "second dvb application" can change the frontend,
>> whithout any chance for the "main dvb application" to detect this
>> easily.
> 
> the dvb-core saving away the last successful LOCK state, will this help
> ? But in any case, the second application if it successfully lock's,
> then this would change logically, since this becomes the
> previous-previous successful locked state.
> 
> Is that what you meant, guess i didn't follow you correctly.

Following scenario (SAT):
   Application 1 tunes device 2:
  to freq  1234.567 MHz, V, HiBand, SAT "2", etc..
   Application 2 tunes device 2:
  to freq  1000.123 MHz, H, LoBand, SAT "1", etc..

  Currently application 1 has no chance to query the current
  frontend settings.

  In a first step, a simple "query current frontend
  settings" (last set data) for a device would be sufficient.
  In a second step (future APIs), one could think about notification
  by event handlers.

  I also would ignore the LOCK state and always save/return the last
  set parameters.


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

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

Hi Manu,

On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
> Please don't remove the CC's. The CC'd people generally don't bother
> about mails from the ML, probably.

sorry, it was definitely not my intention and I hope to include
all previous CC here.

[have to read about the multiproto changes myself...]

> Can you please point me to some ASI specs if you don't mind ?  I was
> once supposed to work on such a device, but then that company itself got
> scrapped, hence never had to figure out on ASI.

Well, AFAIK the ASI specification is not open, so I unfortunately I
can not point to it.
To be honest, the only thing about ASI comes from a fronted we use at
the company in professional equipment, so I am not sure if the things
I can tell from there are really valid for all ASI equipment. However,
as from time to time questions come up concerning DekTec and other boards,
at least some basic support for ASI seems to be desirable.

So, coming to the facts, our ASI frontend gives these as "statistics":
- BER
- sync status
- 204 or 188 byte/packet mode

[...]
> Since it is an IOCTL call straight away within the V3 API, i would like
> to push this into the frontend thread where it is submitted as a job
> kind of thing, where the userapplication can be notified in what
> timeframe, or via GET_EVENTS, final details can be left out for the last
> stage.

This sounds very reasonable for me. I have no idea yet how this frontend
thread is handled now, but after all all necessary information should be
present there (e.g. lock state, to do a proper reset of averaging etc.).

> Scale for BER is one thing that is still open ended, which i am off
> hook. I need to still check on this, but if you have some ideas would be
> nice.

Hmm... I am not sure what is needed by others, so my voice should not
be given too much weight here. We always use 10^-8 as the base, but for
some equipment this might already be too rough. On the other hand, IIRC
some demodulators do not return more accurate values anyways.

> Signal Strength & SNR:
> 
> In reality we can provide 2 ways for the same,
> 1) Relative scale
> 2) a scale in a decibels
> 
> Even with Reverse Engineered drivers we can do 1) but for 2) we might
> need more info. The user could probably select what he needs using an
> IOCTL, relative or an absolute scale. For the relative one we can just
> define a floor and ceiling and a relative value is extracted out.

That is what I was thinking of, for most applications this would be
sufficient. I do not know what is the better solution here. Following
your proposal of two different styles of return values makes life easier
for the application (which could request the "scale" type and just take
this value). Even knowing the exact decibel value would make it necessary
to interpret it differently for different transmission schemes, i.e. 8 dB
SNR in DVB-S is no problem while there would be no reception in DVB-C...
On the other hand it might be confusing to get different values for the
same thing, which I treat as an argument for my proposal of always (if
possible) returning the dB value and giving the application (and user)
the demod min and max values for drawing a nice percentage scale.

For a few demods I could provide the dB calculation (namely STV0299,
STV0288, TDA10046, TDA1002x), but probably these are those with
fewest problems anyways.
For others (e.g. STV0297) there seems to be no calculation possible,
I know of other implementations using a look-up-table. If needed, I
could do some measurements and see if we manage to get good results
with a look-up-table, too.

> know anything. In some cases people would like to get the absolute value
> for some instrumentation reasons.

It makes comparison of different frontends/setups easier, too. At least
in some forums people try to compare their dish and stuff with this, so
not only addicts like us might want to see these values. ;-)

[Sorry for deleting your most interesting part about silicon tuners -
I have not had my hands on one yet, so cannot comment]

> > I understand floating-point is not possible in the kernel, but what
> > other possibilities are there to get rid of the device-dependent snr
> > calculation in the application? Please, no debate about complete user-space
> > driver here! I really hope there are other solutions, but I have no idea
> > what is possible.
> 
> 
> Currently we have a log10 implementation in dvb-core in dvb-math.c We
> can use this for the same, but we will still need some careful hand
> crafted integer calculations, complexity depending upon the hardware
> itself, since it is vendor specific. This also requires that one must
> have proper specifications for the devices for this to be done.

This is good news! I will have a look at current implementation and see
if I can play with it a bit (to test how my above mentioned calculations
fit here). There will definitely be some re-work be necessary, because up
to now I used float calculations w

Re: [linux-dvb] DVB API update

[Marcel Siegert]

On Sunday 16 September 2007, Rainer.scherg wrote:

hi rainer,

> Manu Abraham schrieb:
> 
> > 
> >>   - a "user structure" for hardware specific data (e.g. retrieve
> >> special data from a special frontend chip would be nice.
> >> this should be optional (*NULL = not used or not implemented).
> >> otherwise something like:
> >>struct { char[xx]   hw_info;
> >> specific data...
> >> }  *;
> >>
> > 
> > Sounds good. In a tangent thought, in many cases when a special chip is
> > used sometimes there is an overall change in the hardware design.
> > 
> > In such a case, do you think, that if we abstract such an info, out as a
> > part of as a new object such as an adapter object, (such that more
> > information can be passed out clearly) would be a better approach,
> > rather than shoving everything we have into the frontend object ? (where
> > the adapter object becomes the parent object for all others)
> > 
> > Though i must say, that the frontend specific should be in the frontend,
> > but the adapter object could get the frontend specific information as a
> > part of it's own and present to the application. Though, you will be
> > able to query the frontend related information alone also, for carrying
> > around shorter chunks of data if the user wants to have only a small
> > subset of the information.
> 
> I did not made any deeper thoughts on how this could be implemented 
> best. What was the reason of this idea:
>A university asked me some times ago, to enhance dvbsnoop to output
>more detailled error reporting data than SIG, SNR, BER, UBLCK for
>a specific frontend (DIBCOM3000).
> 
> In this case it was related to the frontend. As you stated, a special
> object might be more useful and more flexible.
> 
> 
> > 
> > 
> >>   - API 3 is missing a a function for retrieving current frontend
> >> settings (e.g. on SAT  LNB settings). It would be sufficient, when
> >> simply the last parameters set are returned.
> >> Currently on API3 a "second dvb application" can change the frontend,
> >> whithout any chance for the "main dvb application" to detect this
> >> easily.
> > 
> > the dvb-core saving away the last successful LOCK state, will this help
> > ? But in any case, the second application if it successfully lock's,
> > then this would change logically, since this becomes the
> > previous-previous successful locked state.
> > 
> > Is that what you meant, guess i didn't follow you correctly.
> 
> Following scenario (SAT):
>Application 1 tunes device 2:
>   to freq  1234.567 MHz, V, HiBand, SAT "2", etc..
>Application 2 tunes device 2:
>   to freq  1000.123 MHz, H, LoBand, SAT "1", etc..
> 
>   Currently application 1 has no chance to query the current
>   frontend settings.

from my pov it would not be allowed to have application 2 tune to a different
transponder if application 1 still uses it.

and, where is the deep sense in this situation?
app 1 tunes to 1234

app 2 tunes to 1000... and therefore destroys app 1`s data

app 1 checks periodically (via get current tuning param), 
if everything still is fine,
the result is this case is no, so app 1 would maybe 
try to retune to 1234-- and app2 would check and try to retune to 100

i cant see sense in your example at all. 

where i can see the sense is, to query a frontend to get back the actual 
frontend settings, 
but your example has a totally different problem.


> 
>   In a first step, a simple "query current frontend
>   settings" (last set data) for a device would be sufficient.
>   In a second step (future APIs), one could think about notification
>   by event handlers.

which notification? a userspace application should free a frontends usage, if 
is no longer
using it. am i wrong?
 
>   I also would ignore the LOCK state and always save/return the last
>   set parameters.
what do you mean with ignoring a LOCK state? also return frontend settings, if 
no LOCK
has been done on those? if that is your point, i am ok for that.


regards
marcel


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi,

Rainer.scherg wrote:
> Some quick thoughts:
> 
>   - the new API should support the DVB API v3.x as an "API layer".
> Otherwise it will take a long time, to get most dvb applications
> running on the new API, which would make it hard to replace the
> current API.
>

We can have compatibility with the V3 API, that's what you meant ? I
guess so.

>   - A runtime version check of the API is needed. Currently the API
> version is determined at compile time, which is useless, when
> distributing binaries (one of the bad things on linux are
> incompatible API changes over time).
> A simple major.minor version number check will IMO do.

Right.

> 
>   - a "user structure" for hardware specific data (e.g. retrieve
> special data from a special frontend chip would be nice.
> this should be optional (*NULL = not used or not implemented).
> otherwise something like:
>struct { char[xx]   hw_info;
> specific data...
> }  *;
> 

Sounds good. In a tangent thought, in many cases when a special chip is
used sometimes there is an overall change in the hardware design.

In such a case, do you think, that if we abstract such an info, out as a
part of as a new object such as an adapter object, (such that more
information can be passed out clearly) would be a better approach,
rather than shoving everything we have into the frontend object ? (where
the adapter object becomes the parent object for all others)

Though i must say, that the frontend specific should be in the frontend,
but the adapter object could get the frontend specific information as a
part of it's own and present to the application. Though, you will be
able to query the frontend related information alone also, for carrying
around shorter chunks of data if the user wants to have only a small
subset of the information.

What do you think ?

>   - enum dvb_fe_modulation {
>   DVB_FE_QPSK = (1 << 0),
>   [...]
>   DVB_FE_QAM_256 = (1 << 5),
>   DVB_FE_QAM_AUTO = (1 << 6)
>   };
> 
> better would be something like this:
>  DVB_FE_QAM_AUTO = (1 << 15)
> so, we have some space for future extensions...


True, this can avoid a dummy parameter, since we would like reserve this
space.


>   - API 3 is missing a a function for retrieving current frontend
> settings (e.g. on SAT  LNB settings). It would be sufficient, when
> simply the last parameters set are returned.
> Currently on API3 a "second dvb application" can change the frontend,
> whithout any chance for the "main dvb application" to detect this
> easily.

the dvb-core saving away the last successful LOCK state, will this help
? But in any case, the second application if it successfully lock's,
then this would change logically, since this becomes the
previous-previous successful locked state.

Is that what you meant, guess i didn't follow you correctly.

Thanks,
Manu


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

Re: [linux-dvb] DVB API update

[Rainer.scherg]

Some quick thoughts:

  - the new API should support the DVB API v3.x as an "API layer".
Otherwise it will take a long time, to get most dvb applications
running on the new API, which would make it hard to replace the
current API.

  - A runtime version check of the API is needed. Currently the API
version is determined at compile time, which is useless, when
distributing binaries (one of the bad things on linux are
incompatible API changes over time).
A simple major.minor version number check will IMO do.

  - a "user structure" for hardware specific data (e.g. retrieve
special data from a special frontend chip would be nice.
this should be optional (*NULL = not used or not implemented).
otherwise something like:
   struct { char[xx]   hw_info;
specific data...
}  *;

  - enum dvb_fe_modulation {
DVB_FE_QPSK = (1 << 0),
[...]
DVB_FE_QAM_256 = (1 << 5),
DVB_FE_QAM_AUTO = (1 << 6)
};

better would be something like this:
 DVB_FE_QAM_AUTO = (1 << 15)
so, we have some space for future extensions...


  - API 3 is missing a a function for retrieving current frontend
settings (e.g. on SAT  LNB settings). It would be sufficient, when
simply the last parameters set are returned.
Currently on API3 a "second dvb application" can change the frontend,
whithout any chance for the "main dvb application" to detect this
easily.






Manu Abraham schrieb:
> Hi,
> 
> Currently the DVB API is of version 3.2. We have had API changes and
> changes to no end to it. In fact there was much learning from the V3 API
> than any other version.
> 
> We have an old V4 API that was supposed to be taking over the V3 API.
> But V4 is considered almost dead due to lack of modern hardware support
> such as SOC's for STB's.
>[...]
> 
> I hope this doesn't mark the beginning of another flame war.
> 
> Regards,
> Manu
> 


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

Re: [linux-dvb] DVB API update

[Manu Abraham]

Hi,

Wolfgang Wegner wrote:
> Hi,
> 
> how should this discussion take place?
> 

Your valuable comments, whatever it is in a positive way can lead to a
good discussion. :)
Please don't remove the CC's. The CC'd people generally don't bother
about mails from the ML, probably.


> Up to now, my personal experience showed only some drawbacks in the
> frontend API, and reading the current proposal v4_0.3 I have some
> comments/questions concerning this part:
> 
> - dvb_fe_type: DVB-S2 is missing and I personally would also like
>   to see ASI here...

the multiproto update can handle S2, DSS, DVB-H possibly looking at
DMB-T/H as well a while later. We can pull in ARIB from V4. We won't use
V4 straight away as it is, it needs an overhaul as well.

Can you please point me to some ASI specs if you don't mind ?  I was
once supposed to work on such a device, but then that company itself got
scrapped, hence never had to figure out on ASI.

> - frontend status:
>   - BER is lacking a proper definition (to which base is it calculated?)
>   - signal strength: same problem, what are the ranges?
>   - snr: again, no base and ranges given
> 
> For signal strength and snr, I already wrote about a possible partly
> solution: provide a means to query the frontend for corresponding min
> and max values (in dvb_frontend_info?).

Some of the aspects that my hands were itching to fix was statistics.

Currently in all the API's  we have, with regards to BER, we have an
issue. BER is in fact averaged by the demod over a short period of time,
with some amount of hardware specific computations. This needs some time
and is not available off hand.

BER:

V3 forces the user application to ignore the first few values of BER and
do averaging. This a crude and a rough way of doing it. In fact since
there is some amount of HW dependency for the same, the computation
should be done by the demod only and not by the user application. The
driver needs to make the computation in a short span.

Since it is an IOCTL call straight away within the V3 API, i would like
to push this into the frontend thread where it is submitted as a job
kind of thing, where the userapplication can be notified in what
timeframe, or via GET_EVENTS, final details can be left out for the last
stage.

Scale for BER is one thing that is still open ended, which i am off
hook. I need to still check on this, but if you have some ideas would be
nice.

Signal Strength & SNR:

In reality we can provide 2 ways for the same,
1) Relative scale
2) a scale in a decibels

Even with Reverse Engineered drivers we can do 1) but for 2) we might
need more info. The user could probably select what he needs using an
IOCTL, relative or an absolute scale. For the relative one we can just
define a floor and ceiling and a relative value is extracted out.

The general user will naturally prefer a relative scale (something like
say 0 - 100 ie percentage to make life simple) since he doesn't have to
know anything. In some cases people would like to get the absolute value
for some instrumentation reasons.


> 
> I know signal strength is very unreliable for most frontends (are silicon
> frontends really better, as claimed from time to time?), but at least
> the snr can be calculated very good for most demodulators. Would it be
> possible to do this calculation somewhere "near the driver" to provide
> a uniform value to the caller regardless of the frontend actually used?
> 

One advantage about Silicon tuners is that the vendor can provide
information on what it's characteristics would be: thus it is well
defined. In the case of a PLL with discrete components: difficult as
there are RF stages involved in the picture.

In the case of a discrete tuner, each vendor can make their specific
changes which will make changes to the Input gain Noise floor etc, and
hence might not be very accurate unless you get specific information
from the "metal can" vendor. In many cases even from the metal can
vendor this information is missing.

The disadvantages of Silicon tuners is that generally they get heated up
fast, once heated up this results in thermal instability and or
additional noise reducing SNR a bit at least. For the first generation
Silicon tuners this has been a curse for which there exists no solution.

Some people provide solutions for this by reducing the gain for the
silicon tuner when unnecessary, since with a reduced gain, the tuner has
a lesser dissipation, but this is not a very effective method as it
brings in only a very small change. Nothing large that we can consider.

In reality it is a hard choice, some vendors still provide a metal can
tuner and advertise as a premium product because of the disadvantages
with the silicon tuners. That said silicon tuners are improving from
generation to generation.

The third generation devices have almost little dissipation, the third
generation devices being used in portable devices and hence dissipation
has to be kept low for all reasons such as powe

Re: [linux-dvb] DVB API update

[Wolfgang Wegner]

Hi,

how should this discussion take place?

Up to now, my personal experience showed only some drawbacks in the
frontend API, and reading the current proposal v4_0.3 I have some
comments/questions concerning this part:

- dvb_fe_type: DVB-S2 is missing and I personally would also like
  to see ASI here...
- frontend status:
  - BER is lacking a proper definition (to which base is it calculated?)
  - signal strength: same problem, what are the ranges?
  - snr: again, no base and ranges given

For signal strength and snr, I already wrote about a possible partly
solution: provide a means to query the frontend for corresponding min
and max values (in dvb_frontend_info?).

I know signal strength is very unreliable for most frontends (are silicon
frontends really better, as claimed from time to time?), but at least
the snr can be calculated very good for most demodulators. Would it be
possible to do this calculation somewhere "near the driver" to provide
a uniform value to the caller regardless of the frontend actually used?

I understand floating-point is not possible in the kernel, but what
other possibilities are there to get rid of the device-dependent snr
calculation in the application? Please, no debate about complete user-space
driver here! I really hope there are other solutions, but I have no idea
what is possible.

Best regards,
Wolfgang


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