In the new year, Johannes Stezenbach wrote: > > On Fri, Mar 14, 2003 at 12:40:17PM -0500, Jeremy Hall wrote: > > Well, to put it another way, when the userspace program requests a section > > filter, and starts it, what exactly does the driver prepare for it? The > > user gets the section length from the second and third bytes of the > > section. If those are corrupt, and they are still less than the buffer > > size, the userspace application will read however much data it was told to > > read, we can't recover from that. Then when we've read part way into > > another section, how do we get resynched with section boundaries? > > > > If they are corrupt and larger than the userspace buffer size, how does > > the userspace program know how far to read ahead to find the next section? > > If CRC failure is detected, is it best to close and reopen the filter? > > The section length field has 12 bits, so if you use a buffer of > 4096 bytes length for your read, you will alwas get one full section > per read() call (the API guarantees that). If you find the section to be > broken, throw it away and read the next one. > > OTOH the API also guarantees that you never get broken sections > if you use DMX_CHECK_CRC (provided the section_syntax_indicator is 1). > The av7110 implementation must be fixed. > > The reason that it's broken now is that the AV7110 has hardware for the > CRC check, but no one got around implementing the check in the > firmware. Or maybe the Metzlers tried and it didn't work. Anyway, it's > simpler to implement it on the PC now. If someone sometime implements > it in the firmware, the check on the PC can be eleminated... > I don't mind doing it in the PC, my goal right now is to figure out why the arm is crashing.
One thing I am looking at now is line 1011 of av7110.c, if (av7110->handle2filter[handle]) Could this create a race condition with its counterpart 3 lines down? or could this be optimized to avoid the same call twice? _J > > Regards, > Johannes > > > -- > Info: > To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as > subject. > -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
