# Re: Re: [snapscan] More USB updates

From: cbagwell@sprynet.com
Date: Sun Nov 19 2000 - 19:21:05 PST

- Next message: Kevin Dalley: "Suggested adding target install-strip for sane"
  - Previous message: Steve Underwood: "Re: [snapscan] More USB updates"
  - Maybe in reply to: Steve Underwood: "Re: [snapscan] More USB updates"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  Steve, thanks much for the feedback! Yes, this circular buffer stuff is confusing to me as well. I still don't grasp it totally...

  > Lawrence was a bit confused about the purpose of this code, too. Here is a copy of an off list explanation I sent
  > him..........

  > There is a limitation in the work I did, that if you try to scan a Y > line
  > image you will actually get Y - b lines of scan, where b is the > number of
  > lines absorbed by the circular buffering process. It shouldn't >

  > Anyway, that's not your problem here, as the scan you are attempting > is large.

  Is there a chance you could expand on the circular buffer and how its used for me. How do you mean "absorbed"? Does it totally go away or is there some sort of drain()'ing going on at the end that flushing out the buffer?

  > The above code should be OK, if my assumption is right. If
  > TxSource_remaining() is less than one scan line less than the size > of the
  > circular buffer there will be major trouble!

  > The question you need to answer is how does:

  > [snapscan] inquiry: expected total scan data: 25158951 bytes

  > lead to:

  > [snapscan] TxSource_remaining =30592

  Here is what was going on when I run in to the problem. I am
  performing a 600 dpi scan of a predef-window = 6x4. Results in the
  following initial values:

  [snapscan] inquiry: pixels per scan line = 3599
  [snapscan] inquiry: bytes per scan line = 10797
  [snapscan] inquiry: number of scan lines = 2407
  [snapscan] inquiry: effective buffer size = 21594 bytes, 8 lines
  [snapscan] inquiry: expected total scan data: 25988379 bytes
  [snapscan] measure_transfer_rate: have ring buffer

  Now, notice that I'm right at calling mesaure_transfer_rate() to do
  the fake scan of a few lines (rounded to a 128 byte boundry). There
  is an initial call to scsi_read() so that we get 1 read from the
  scanner. Then it does a create_source_chain() which among other
  things forces cb_start = -1.

  This is an immediate case were the circular buffer hasn't read
  anything but we have data to process and its going to be less
  then the circular buffer's total size. I'm getting values similar
  to TxSource_remaining() = 21594 cb_size = 91000 and cb_line_size = 10797. Do the math and you get a very negative number coming
  out of RGBRouter_remaining() since cb_start = -1.

  The reason the buffer sizes don't match is something to do with
  RGBRouter_init() is multiplying the buffer size by some factor
  related to each R, G, B value it needs to read but the
  measure_transfer_rate() function is not taking the same thing
  into account.

  Any pointers? Currently, I'm thinking its better to simply have
  it return the value from TxSource_remaining() when cb_start == -1.
  This cures my problem but perhaps it trashs data at the end of the
  scan where there was already a good chance it was going to be
  trashed anyways??? Thoughts?

  Thanks much,
  Chris

      --
      Source code, list archive, and docs: http://www.mostang.com/sane/
      To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

  - Next message: Kevin Dalley: "Suggested adding target install-strip for sane"
  - Previous message: Steve Underwood: "Re: [snapscan] More USB updates"
  - Maybe in reply to: Steve Underwood: "Re: [snapscan] More USB updates"
  - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

  This archive was generated by hypermail 2b29 : Sun Nov 19 2000 - 19:07:12 PST