Potential RF line buffer size mismatch in BK ProFocus image source

[Sunderlandkyl]

The following warning in PlusBkProFocusReceiver.cxx is displayed in certain cases:

LOG_WARNING("Not enough space allocated to store all the RF samples. Input: "<<numberOfSamplePairsInInput<<", output: "<<numberOfSamplePairsInOutput);

Currently the warning has been disabled to reduce clogging of the error log, but we should investigate why this happens and fix it. If the warning is displayed then scanlines are cropped and axial spacing after scan conversion may be incorrect.

Even if we don't understand why the scanline length is inconsistent between Prepare and DataAvailable, we could dynamically allocate a larger buffer if we find that the already allocated buffer is too small.

Migrated from https://app.assembla.com/spaces/plus/tickets/701/details

[Sunderlandkyl]

2013-03-15 17:59
Andras Lasso
@fedorov:
Do you have an idea why we see this warning now and why it wasn't displayed before?
Maybe because we switch probes and Prepare is called only once?
What are the logged numberOfSamplePairsInInput and numberOfSamplePairsInOutput values?

2013-03-29 09:13
Andrey Fedorov
Andras, I think this warning has always been there. I think I looked into this before, but don't remember what I found. I will look again.

2013-03-29 09:49
Andras Lasso
It would be great if you could investigate, as when the warning case happens then the end of scanlines are discarded.

2013-03-29 09:54
Andrey Fedorov
(In plus:2629) re #701: adding 6 to numberOfRfSamplesPerLine eliminates the buffer size mismatch. Perhaps there is a fixed size header that is prepended. Tested both with curved and linear arrays on BK 8848.

2013-03-29 09:58
Andrey Fedorov
(In plus:2630) re #701: added comment for the previous commit change

2013-03-29 09:59
Andrey Fedorov
See commit 2629: this fixes the mismatch. Do you think this is a reasonable solution, or we really need to understand where this is coming from?

2013-03-29 10:58
Andras Lasso
It's a reasonable temporary solution, but the best would be to do some more debugging or ask BK developers to find out what causes it exactly.

We already know that there is a header (ResearchInterfaceLineHeader) of HEADER_SIZE_BYTES long, but maybe
the header is actually longer, or
there is a footer as well (there is a ResearchInterfaceLineFooter type in Grabbie's ResearchInterface.h, so it seems quite possible), or
we have to use header->LineLength to determine the actual number of samples (and then there is a footer and the rest is just padding)