<snip> > Right now I have an app running that visualizes the input from the > scanner in real time. At 50 dpi I get ~30 lines/sec, at 1200 dpi ~60 > lines/sec.
you've done pretty well up to this point. > q1: Why are the lines returned in "chunks"? By this I mean sane_read will > block for so many milliseconds, and then the next ~1-32 calls to > sane_read will all return seemingly instantaneously. I tried going into > non-blocking mode, but the &size that is passed as the final argument to > sane_read seems to exhibit the same behavior: it doesn't "fill up" for a > while, and then all of a sudden it fills up multiple lines. Right now I'm > dealing with this by buffering 32 lines, and limiting the rate at which I > read from the buffer. This isn't ideal, as it introduces some latency, > but it works. I cannot speak to the specifics of the LM9xxx chipset, but most of them have a small internal buffer, and cache a few lines for sending to the host at once. You could try to modify the code to ask for smaller chunks, but many such machines have a minimum size. Those that don't, often have a minimum have performance problems (dropped lines, buffer overflows) if you dont drain the buffer fast enough. > q2: Is there any way to force the scanner to stay in the sane_read loop? > It was mentioned that some models don't have any notion of "paper > length", but this one definitely does. One of the geometry options is > "y", which ranges from 0 to 297mm. There is a (relatively) long pause > between consecutive pairs of sane_start/sane_read/sane_cancel blocks, and > I'd like to avoid that if possible. If the scanner hardware itself has a concept of page length, then it won't keep scanning at the end. As i said previously, the hardware is more important than the software here... allan -- "The truth is an offense, but not a sin"
