Andrew de Quincey wrote: >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. > > Hardly. I'm afraid of the reorg not going far enough... Go through the archives and find the messages where I talk about going through a layered approach with blocking/non-blocking calls... >>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. > > Well, you could have a pointer to a buffer allocation strategy that the user could override. I guess I don't 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. ;-) >>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. > > It might be a switch/positioner issue. Further, what happens if you have multiple steerable dishes or a toroidal dish with multiple LNB's? You might want to see if one of the LNB's is already locked up to the appropriate position and polarity... That would avoid using up resources unnecessarily (but then you'd also have to manage locking, so that the first process couldn't decide to move the dish or change the polarity now that it's being "shared"... so some sort of semaphores might be required). >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... > > Hmmm.... this is a recurring theme... Most of the development is done by people with limited means to test more complicated set-ups... >I'd 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. >>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 aren't sufficient... and that this isn't the place to put them. A satellite's information isn't 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...) On the other hand, the user's 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. >>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 don't think that 40-100 bytes is going to break an STB (and yes, I've worked making STB's). Having config files that are easy to create and verify make it easier for resellers/carriers/installers to tailor to their users... >>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 couldn't figure out much just from looking at the same data... >>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... > > I'm confused. Won't your changes break compatibility with the existing applications? If so then you'll need to patch, at a minimum, the applications that you use... unless you use only 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 won't. Have a look at: http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/position_app_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. -Philip
