> I do not believe this would be very easy to use. All > the stuff > like frontend control might be time critical, > depending on > which frontend you use, so IMHO it would be > desirable to have > the complete frontend driver inside the box. Examples? Remember that most tuner modules use i2c for all control (tuning, checking lock status, LNB control, Diseqc, etc). Considering the time required for 100khz I2C messaging, the additional time contributed by transport over 100mbps Ethernet on a LAN is negligible. > And also the control packets to the device would > require > some kind of protocol - of course it does not need > to be > TCP, but it could make things more flexible from the > softwae > point of view. At least for a first version, I lean towards simplicity. The control messages would consist only of i2c messages, and pid filter control. A UDP packet would be enough to convey these messages, and would make implementation easy. > The timestamp thing I was talking about would > require a > modified UDP/RTP, but then would be able to take > into account > the packet delays during the way through the > network. We did > get an accuracy of around 10 microseconds at a > wireless node > behind a router with this protocol, which of course > is not > good enough for DVB (ASI) requirements, but good > enough for > A/V sync. What kind of timestamp would you like to see? IIRC, RTP uses the 27mhz clock from the STC. We could append a local 32-bit timestamp as well to each packet as it arrives. Would this suffice? Regards, Brian __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/
