[linux-dvb] RE : linux-dvb and Dektec [was: DVB API update]
thierry.lelegard at tv-numeric.com
Wed Oct 3 16:42:20 CEST 2007
IMHO, the Linux DVB framework serves two main purposes:
- Common API for the zillions of DVB-S/C/T adapters
- Common frontend for TV watching programs such as Myth et al.
Dektec products address the market of professional & test
lab applications using ASI input/output, QPSK/QAM/OFDM modulators
They address separate needs, separate usage.
I have been using both linux-dvb and Dektec products for years and
found no real use in integrating both.
Also, as you pointed out, Dektec products can be either input, output
or both. Their output products also include very nice modulators on
PCI boards. I presently use a DTA-110T, a DVB-T modulator.
Since linux-dvb is an input-only framework, it would address only
part of Dektec products (and even part of a device in the case of
I develop and use test lab applications for my own usage. I need to
receive and send transport streams. I have my own TS processing
framework in userland, with input and output "plugins" (such a
trendy term ;-). I have separate input plugins for linux-dvb and
Dektec. I have a Dektec output plugin, but none for linux-dvb of course.
This is of course a specific professional usage, not a home TV-watching
program. Who's going to watch TV at home from an ASI feed ?
I think that remaining in userland is better approach for that.
At the beginning, before I really understood I went the wrong way,
I developed a "loopback" linux-dvb frontend. It was a kernel driver
which integrated with linux-dvb and that was fed by userland applications.
The TS coming from these userland applications was presented as coming
from a linux-dvb device. Since there is no generic frontend class,
my driver pretended to be a QPSK frontend and silently ignored
So, a userland application could read a TS from anywhere (a Dektec
device, a file, IP multicast, whatever) and feed the dvb loopback driver.
Then, any linux-dvb application was able to play with this TS.
But, apart from the useless pride of being a "kernel code developer",
this was totally useless and I gave up this driver. There are simpler
userland alternatives for that.
Going further, I think (no flame please ;-) that having the full
linux-dvb in kernel space has become a conceptual mistake nowadays.
The amount of kernel code should remain as small as possible and
limited to hardware device access. A software demux has nothing to
do in kernel space. IMHO, there should be a userland API that does
this. The kernel drivers should report the capabilities of the
hardware devices, such as demux. If the device has demux capabilities,
the userland code sends the PID filter to the device. Otherwise, the
complete TS is passed in userland and demux is done in the API.
Demuxing is just one example, all non-hardware related features
of linux-dvb should be moved out of the kernel.
This is a common disease of open-source developers who are sometimes
too much "ego-driven": they want to be part of the small "kernel
coders" community and add features in the kernel for fun. It is
a well-known debate about the Linux kernel being to bloated.
Anyway, coming back to linux-dvb and Dektec, kernel drivers exist
for both, just write userland code to access the one you want.
De : linux-dvb-bounces at linuxtv.org [mailto:linux-dvb-bounces at linuxtv.org] De la part de Andrea Venturi
Envoyé : mercredi 3 octobre 2007 15:10
À : linux-dvb
Objet : Re: [linux-dvb] DVB API update
Manu Abraham wrote:
> 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 :
> If someone has the hardware, we can take a go at it.
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:
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!
>> Best Regards,
>> Simon Hailstone
>> On 16/09/2007, *Wolfgang Wegner* < wolfgang at leila.ping.de
>> <mailto:wolfgang at leila.ping.de>> 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
>> 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
>> > 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
>> > 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
>> 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
>> > 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
>> > > 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 without much thinking...
>> > Thanks,
>> > Manu
>> Best regards,
>> linux-dvb mailing list
>> linux-dvb at linuxtv.org <mailto:linux-dvb at linuxtv.org>
> linux-dvb mailing list
> linux-dvb at linuxtv.org
linux-dvb mailing list
linux-dvb at linuxtv.org
More information about the linux-dvb