Kenneth Aafløy wrote:
Hi!The point is that hardware demux filters are a limited resource that needs to get managed. You can't use more at once than you have available in your demux unit -- if you need more you have to perform some kind of scheduling. Or use software filtering.
I've sent this to Michael, but never got a reply (that's happened before), is it just insane?
What really annoys me is that when I want to do a simple demuxing task, such as harvesting all the PMT's, I have to set up a chain of fd's and do rotating and stuff, to avoid the demux fd limit. I have not checked wether it is possible to do a section filter on multiple pids in the new api, but it would be a feature I would like if not.
I would also have done something like this:
struct dvb_dvb_s_parameters {
uint32_t symbol_rate;
enum dvb_fe_code_rate fec_inner;
dvb_sec_voltage voltage;
dvb_sec_tone_mode tone_mode;
dvb_sec_tone_burst;
};
Which would get rid of four ioctls. I belive this would clean up the interface a lot, and also, since most of the userspace frontend code is in one location, it would clean this up too. Would also allow userspace to only change one parameter of the frontend, and allow for special flags like disable zigzag, which would help with applications trying to autodetect what equipment is on a dvb-s frontend (I'm working on a app that does this..). The diseqc send/receive would still be separate, as those really act more like a bus interface.DiSEqC send and receive are tightly coupled to the set voltage/tone commands, you can't decouple them since the DiSEqC spec requires you to set them up in a well-defined order. The test/diseqc.c test program shows how.