[sane-devel] continuous capture from scanner
m. allan noah
kitno455 at gmail.com
Sat Jul 25 12:02:20 UTC 2009
> 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...
"The truth is an offense, but not a sin"
More information about the sane-devel