> Yes, it applied without problems. Thanks. However, it didnt solve the
> problem. Even with high buffer sizes the scanner continues to do exactly
> the same (speedwise and in behaviour). The problem therefor must be
> either in the backend or the scsi card/driver.
>
> In order to try and see if i could discover what was wrong i set
> SANE_DEVEL_MUSTEK=255 and received this strange messages:
> [mustek] reader_process: 352176 bytes read.
> [mustek] mustek.output_data: data=0x40914008, lpb=92, bpl=3828,
> extra=0x40b14008
> [mustek] start color: 0
> [mustek] read lines: 276
> [mustek] saved lines: 4/0/2
> [mustek] available: 50/46/48
> [mustek] triples: 46
> [mustek] read 4096 bytes
> [mustek] read -1 bytes
The backend starts a reader process which reads the data from the
scanner and sends it via a pipe to the parent process. The lines "read
4096 bytes" / "READ -1 bytes" are written by the parent process; it
simpy means that you can only write/read blocks of 4096 bytes to/from a
pipe. This does not necessarily mean that the reader process reads only
blocks of 4096 bytes from the scanner.
I don't have worked much with a Mustek scanner, and I have neither
worked on the backend, so I might write now some nonsense, but anyway:
You can try to change the line
#define REQUESTS 1
to
#define REQUESTS 2 (or may be 3)
in mustek.c and recompile the backend again.
If I understand the source code right, the backend should then queue two
resp. three read commands. This alone does not necessarily help, since
AFAIK the Linux kernels contain up to now the SG driver version 2.1.34,
and this SG version does not yet support "driver level" queueing. In
this case, the queueing logic is done within sanei_scsi.c, and this
means that the pipe might remain a bottleneck. Upgrading to SG version
2.1.35 should help in this case. You can download the SG driver from
http://www.torque.net/sg/
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com