OSX - figure out good default buffer size about soapyremote

[guruofquality]

I may have recently "fixed" something in regards to reporting the error from setting the socket buffer. Has any behaviour actually changed other than the error message appearing. I assume the stream of SSSSS's were not there prior?

I never tried remote before, so i cannot tell you.

Ton.

On Sun, Nov 1, 2015 at 7:49 PM, Josh Blum [email protected] wrote:

I may have recently "fixed" something in regards to reporting the error
from setting the socket buffer. Has any behaviour actually changed other
than the error message appearing. I assume the stream of SSSSS's were not
there prior?

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

[guruofquality]

OSX is a little strange with the socket buffer sizes. We tried to pick a default on that would be acceptable. Some notes here: https://github.com/pothosware/SoapyRemote/blob/master/common/SoapyRemoteDefs.hpp#L38

So then the resize fails like this, the actual size isnt known, and the flow control may not properly protect the socket buffer from overflow (thats the S printed). On linux, the resize never fails, it just comes up short. @cjcliffe When we last looked at this, did you have to change any OSX parameters to allow for the 16k buffer size?

So we need to figure out an acceptable default size, or some algorithm to determine the size-cap without erroring out, and to make the size readback robust as well, so we always know the actual size, even in the event of failure to set the size.

[guruofquality]

This commit should readback the proper window, even after buffer resize fails. Plus better logging: 9f7a887

@Toontje Can you experiment with reducing #define SOAPY_REMOTE_DEFAULT_ENDPOINT_WINDOW (16*1024)? Im curious at what value it stops failing.

[cjcliffe]

I assume it's an RTL dongle since I see the remote format as CS8 -- Not sure if it's related, but the following hack from when we were trying to figure out what was up with SoapyRemote+RTLSDR+OSX is still active on the version of CubicSDR that @Toontje is using:

    if (deviceArgs.count("rtl") != 0) {
        streamArgs["remote:mtu"] = "8192";
        streamArgs["remote:format"] = "CS8";
        streamArgs["remote:window"] = "16384000";
    }

That code has already been removed in my local commits as I'm adding all the stream and device settings into the device selection dialog which will let you change this stuff manually.

[guruofquality]

Really old bug. OSX has different ifdef sizes here for this reason.