> >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. ;-) 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 doesn't 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: 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). 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; 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... Unfortunately yeah. Although I do some of this work for my company, we don't 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 :( > >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. 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 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...) 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)... You're effectively suggesting merging these two? In that case, I'm 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 isn't 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 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. 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 didn't 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 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... 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 don't 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 couldn't 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... > > 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... 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 > won't. > > Have a look at: > > http://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 you're interested.
