Rob.McConnell@Zarlink.Com wrote:
yes, the early demos used the NEWSTRUCT/v2 API with basically the same architecture, the newer ones v3.Johannes Stezenbach <js@convergence.de> wrote on 07/09/2004 17:36:53:Rob.McConnell@Zarlink.Com wrote:Johannes Stezenbach <js@convergence.de> wrote on 07/09/2004 16:30:02:Rob.McConnell@Zarlink.Com wrote:I don't want to get into a trap where we have the situation where ourorsomeone else's s/w cannot run fast enough on our h/w and we need to redesign the API and go through the design cycle again. Do you haveanyfigures for cpu loading (e.g. top) or profiling?I have no hard numbers for you, sorry. We had demos running on a dbox2 (66Mhz ppc) and ARM Integrator (IIRC ~60Mz ARM7TDMI, with a full-featured av7110 in a PCI bus slot). But that was a while ago. Our current platforms have 150..200Mhz.
Would I be correct in assuming that the dbox2 and ARM demos were/are
running the V3 Linux API? Do you have full EPG and MHP running on the
66Mhz ppc and/or higher spec platforms without any problems using the V4
API?
as far I remember not in normal load conditions. It's important that the queue's data shuffling code runs in interrupt context and thus executes with 'higher-than-realtime'-priority and swamps out any high-latency code currently running.Do you ever get loss of data?
probably... will you be allowed to report the results and possible bottlenecks in the architecture (if you find some) on this list?You could get an old dbox2 and run the V3 API stuff from tuxbox.org on it, and see if you have performance problems. Or maybe someone else with a dbox2 could help you out with some simple benchmarks like running dvb-apps/test/test_section on some TS/PID along with top?Hmm, I think the best thing I can do is spend some home hours porting the V4 API to our current solution and measuring the performance.