Increase SAMPLES_TO_TRANSFER

[fredclausen]

I was seeing SoapySDR readStream failed: OVERFLOW appear in my logs with some frequency while using SoapSDR + Soapy AirSpyHF in conjunction with dumphfdl. I realize the issue is likely my computer is being hamstrung in some way (CPU usage or USB bus being slow).

Increasing the buffer size appears to solve the issue and allow the program to keep up with the buffer.

[touil]

Why not fix SoapySDR (or whatever code is using it) instead of imposing a shitty latency for everybody else?

[luzpaz]

@fredclausen is there an upstream ticket for this ?

[fredclausen]

@luzpaz there is not. I don't know if the issue is in this library, Soapy, SoapySDRPlay or dumphfdl. Based on the reply from the library author I investigated a little more as to why this solution "fixed" my problem and I chose to take the easy route and buy two new computers to run this stuff on because I suspect the issue I was facing was simply USB bus speed issues/number of devices I had connected on the original computer. I still the issue, but it's significantly more intermittent. I don't believe in the current setup I should see it at all, but it is what it is. Bus speed, computational power, memory etc are not constrained on this system.

My suspicion if I'm honest is that there isn't a single causal factor, as software unrelated to my use case (RTL SDR Airband to mind) had this problem with this library/soapy/soapysdrplay and their solution if my memory is correct is to catch the error and ignore it. If I'm correct, this commit is where they're doing that.

I admit I don't fully understand why increasing the buffer size is a bad thing, but I do trust that I'm not qualified to make the judgement and I rolled the change back on the software I'm using. Honestly, I'm at the end of my technical ability to understand and diagnose who or what was causing the issue and open appropriate issue(s).