Sorry if I missed your original mail, I've been having a holiday from DVB stuff. I assume you have no problems with the reorg itself. > I don't think malloc()/free() per se is bad. Especially when it's not done > extremely dynamically... we're talking about doing it once when an > application starts, and returning it all when it ends. Fragmentation and > leaks should be a minimal concern. > > More of an issue would be the use of lots of stack space for copy > constructors, which C++ loves to use. They use alloca() aggressively, > which can tank your stack. 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. > 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: you've got a tri-mode tuner card, and it's 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 haven't 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. 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; I'm happy to add support/include patches for more complex things though... I'd want to keep the more primitive API as well, since different uses have different requirements. > 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? > 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. > 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. > 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... 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?
