| title: | linux dvb Rationalising dvb apps lib s any |
|
Johannes wanted not to have any malloc/freeing in that SI parser, since it
will be used to handle very high data rates. I agree malloc/free elsewhere
is ok; I use it myself in the dvbcfg libs, where it happens infrequently.
Well, you could have a pointer to a buffer allocation strategy that the
user could override. I guess I dont know enough about SI parsing to know
why one would have to create a lot of buffers on the fly.
Feel free to set me straight. ;-)
I think he wanted to have it so it would do the minimum possible amount of
copying/work on the SI data for highspeed datastreams. In the libsi2, it
basically processes the received data in place. What I do doesnt actually
need this efficiency, but the library already had it. Johannes would be the
best person to ask for more info on this.
A while back, I sent some comments about how the libraries work,
and what might be done to improve them.
For instance, having applications ask for a type of adapter, and
having the system probe for all available (unused) adapters, detect
their type, and returning the matching kind. Why? Imagine the
following: youve got a tri-mode tuner card, and its connected
to a Spaun Diseqc NxM switch... The source can be chosen
dynamically from off-the-air, cable, or satellite, and the front-end
can be dynamically selected to be DVB-T/ATSC, QAM256, or
8QPSK. Do you really want to burden the application with that
logic? And do you want to have each application handle that
configuration state differently?
This is what the combination of all the dvbcfg file formats does (well I
think; but I may be missing an important point - tell me if so!). I simply
havent had the time to write the support yet. libdvb2 would have a high
level tune() function simply taking a GSID which works as follows:
1) The GSID is parsed into source_id, UMID and USID.
2) It locates a free adapter in adapters.conf which supports that
source_id. 3) The DISEQC command string is looked up in diseqc.conf for
that source_id and sent to the switch.
It might be a switch/positioner issue. Further, what happens if you
have multiple
steerable dishes or a toroidal dish with multiple LNBs? You might want
to see if
one of the LNBs is already locked up to the appropriate position and
polarity...
That would avoid using up resources unnecessarily (but then youd also
have to
manage locking, so that the first process couldnt decide to move the
dish or
change the polarity now that its being "shared"... so some sort of
semaphores
might be required).
These are all good points. They need serious research, planning and thought.
4) Next, it looks up tuning information for the multiplex in
multiplex.conf using the UMID, and tunes the card.
5) Finally, it looks up the channel information in multiplex.conf using
the GSID and sets up the PID filters.
Is this what you mean? Or am I missing a usage case. Bear in mind all the
DVB hardware I have access to is single mode only, wired to pretty dumb
switches; Im happy to add support/include patches for more complex
things though...
Hmmm.... this is a recurring theme... Most of the development is done
by people
with limited means to test more complicated set-ups...
Unfortunately yeah. Although I do some of this work for my company, we dont
require any more complex setup. I suppose this is what you get with people
doing it in their spare time with little or no manufacturer support :(
Id want to keep the more primitive API as well, since different uses have
different requirements.
Sure. Low-level diagnostics and scripting tools should have low-level
access.
Maybe even adding .xs stubs for Perl scripting.
Now that is a good idea; now we are getting some kind of library, other
language bindings would be cool. I can imagine there could be lots of
interesting things if we have perl and python bindings...
I also think that we could do a better job abstracting the various
kinds of Diseqc support that applications use... whether one is
using a toroidal dish with a switch or a single LNB with a rotor,
this sort of detail should be contained in the configuration, but
abstracted away from the application.
Do you mean something beyond the libdvbcfg diseqc.conf file format? I was
attempting to make that a way to specify that sort of thing.. do you have
ideas for extending it/a better implementation?
Yes. I propose using nesting... having a hierarchy of
satellite/transponder/frequency/
streams...
I also think that simple Diseqc strings to manipulate a switch arent
sufficient... and
that this isnt the place to put them.
A satellites information isnt site-specific: the position, angle,
frequencies, transponder
ids, etc. are invariant WRT the user. (In fact, the CVS could have a
single monolithic
file that the user then extracts the useful lines from...)
So we basically need another config file to describe the invariant technical
details for each transmission system (I dont want to call it "satellite"
since we need to support all systems). Could the "sources.conf" file be
expanded to contain this? Currently it just contains an ID and a human
readable description. I was envisaging the sources.conf to be a file held on
a wellknown system (e.g. linuxtv.org) that applications downloaded when it
was updated, much as you suggest.
We _almost_ have that hierarchy; simply that the sources information is stored
in a separate file (sources.conf) from the multiplexes (multiplex.conf)...
Youre effectively suggesting merging these two?
In that case, Im not sure I entirely agree the frequencies are totally
identical; depending on the card/dish/cables/hardware etc you do get some
variation... e.g. reading the actual frequency the card reported locked it
locked to back and saving it out again in order to accelerate lock times. But
I suppose it would just be a matter of a localised version of the file,
autoupdated by the application.
Hmm, will think about the merging idea; I think the main reason it isnt in
the same file is because I got the idea originally from VDR which has a
separate sources.conf. People might say they want to have seperate files for
each transmission system; but theres nothing stopping them - the libdvbcfg
library would support either method of doing things.
On the other hand, the users hardware configuration is extremely site
specific by
definition. So information about manipulating voltages, tones, input
ids, rotor angles,
rotor presets, etc. should all go into a separate file.
To me, this sounds almost exactly like the diseqc.conf file. I know the IDs
that are currently used to key the information contain the orbital position
of the sat, but they could be anything really; the orbital position was
simply a good way to unqiuely identify each sat cluster since there didnt
seem to be another system. The IDs were meant to be opaque - even though they
might contain something like "S-13E", it could very well have been
"S-Hotbird156".
Lastly, the configuration files could be more flexible, and more
human readable. Embedding "7" for the FEC rather than "7/8"
is less clear than it could be, and risks breaking should the enum
values change in a future release of the kernel.
Which configuration format were you looking at? The libdvbcfg
multiplex.conf ones use either 7 or FEC_7_8, depending on what the
application wants (the first is for machine-readable-only files on STBs
with limited space, the second is for human edited files). I was asked to
add the "brief" format by STB manufacturers concerned about the space
used by the new file formats.
I really dont think that 40-100 bytes is going to break an STB (and yes,
Ive worked making STBs). Having config files that are easy to create
and verify make it easier for resellers/carriers/installers to tailor to
their
users...
Hmm, its more than than 40-100; maybe 40-100 per multiplex, but if you have a
lot of multiplexes it would add up. I dont actually need this saving myself,
but I added it because there was a demand for it from several people. The
library is switchable between both formats at runtime, so I felt it was best
to leave it up to the users of the lib what they choose to do.
All of the satellite information, position, positioning info for a
rotor or toroidal dish (i.e. which switch input, what stored position,
or what angular azimuth and elevation for a 1- or 2-axis position),
the frequencies, transponder numbers, beacon frequencies, sids,
aids, pids, vids, encoding and encryption methods, etc. should all
go into a single configuration file (but a structured, heirarchical one).
Most of that already is in the libdvbcfg multiplexes.conf file. I decided
that keeping diseqc.conf, adapters.conf, and sources.conf seperate was
better from my POV, since I want to share some data (i.e.
multiplexes.conf), but keep other, machine specific data in seperate
files.
Is there a man page that discusses these file formats? I was looking at
test/test_multiplex*.txt
but couldnt figure out much just from looking at the same data...
It should all be documented in the libdvbcfg header files.
Priming and editting that file should be done by the dvb-apps package,
not by applications.
Applications should be patched to use a higher level abstraction of
the libraries (and indeed, developping these patches and re-verifying
that the applications continue to work would be a reasonable way to
confirm that the libraries are correct and functionally adequate).
I agree. However my current priority is to get these libraries working for
my uses. The existing apps are working as they are currently; but if
someone else wants to patch them...
Im confused. Wont your changes break compatibility with the existing
applications?
If so then youll need to patch, at a minimum, the applications that you
use... unless
you use only in-house applications...
Yeah, thats it exactly: I only use in-house applications.
Can you explain how rotor dishes are commanded? I have no experience of
them whatsoever. Would the current diseqc.conf format suffice? or could
it be better?
Depends on the type of positioner... Some move in a single axis, some
move in two
axes...
Some will give you status information as they move (since various
conditions such
as dish weight, snow load, wind, angle, etc. can affect their stepping
speed). Others
wont.
Have a look at:
rel="nofollow" www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/position_ap www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/position_ap
p_note_v1.pdf
BTW: Some positioners will also turn a directional antenna to point the
antenna
for optimal signal strength and front/back discrimination on terrestrial
antennas.
They are programmed in a similar fashion.
Cool, I shall have a read.
Hmm, dishes that send DISEQC data back are not going to work that well - AFAIK
we only have one supported card that might possibly support that, and no one
AFAIK has actually tested if it actually works (I added the code just in
case, but have no DISEQC 2.0 hardware). Its the new s5h1420 DVBS card if
youre interested.
|
