Thank you very much for your help with the installation of soapy remote. I have been listening to GQrx and win7 pro from my local network for 19 days and I am very satisfied. Will it be possible soon to access SoapyRemote from the public ip ?. Is there any other sdr client that works from windows 7?

Seem to be able to get this to happen quite frequently.
Running SoapySDR on Ubuntu 16.04
Running Pothos GUI on Windows, this is the main error I could find on the windows side:

11:21:45.894707] PothosGui.EnvironmentEval: zone[]: I/O error: RemoteProxyEnvironment::transact(): connection inactive - Remote environment crashed

Output on the linux side:

SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept([::ffff:192.168.0.180]:20717)
Segmentation fault (core dumped)

And output after starting strace and replicating:

select(4, [3], NULL, NULL, {0, 50000})  = 0 (Timeout)
select(4, [3], NULL, NULL, {0, 50000})  = 0 (Timeout)
select(4, [3], NULL, NULL, {0, 50000})  = 0 (Timeout)
select(4, [3], NULL, NULL, {0, 50000})  = 0 (Timeout)
select(4, [3], NULL, NULL, {0, 50000})  = 1 (in [3], left {0, 12507})
accept(3, {sa_family=AF_INET6, sin6_port=htons(20776), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 6
setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(6, SOL_TCP, TCP_QUICKACK, [1], 4) = 0
getpeername(6, {sa_family=AF_INET6, sin6_port=htons(20776), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
write(1, "SoapyServerListener::accept([::f"..., 58SoapyServerListener::accept([::ffff:192.168.0.180]:20776)
) = 58
clone(child_stack=0x7f436cd84bb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f436cd859d0, tls=0x7f436cd85700, child_tidptr=0x7f436cd859d0) = 28370
select(4, [3], NULL, NULL, {0, 50000})  = 1 (in [3], left {0, 41046})
accept(3, {sa_family=AF_INET6, sin6_port=htons(20777), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 7
setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(7, SOL_TCP, TCP_QUICKACK, [1], 4) = 0
getpeername(7, {sa_family=AF_INET6, sin6_port=htons(20777), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
write(1, "SoapyServerListener::accept([::f"..., 58SoapyServerListener::accept([::ffff:192.168.0.180]:20777)
) = 58
clone(child_stack=0x7f436e430bb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f436e4319d0, tls=0x7f436e431700, child_tidptr=0x7f436e4319d0) = 28371
select(4, [3], NULL, NULL, {0, 50000})  = 1 (in [3], left {0, 33794})
accept(3, {sa_family=AF_INET6, sin6_port=htons(20778), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 8
setsockopt(8, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(8, SOL_TCP, TCP_QUICKACK, [1], 4) = 0
getpeername(8, {sa_family=AF_INET6, sin6_port=htons(20778), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
write(1, "SoapyServerListener::accept([::f"..., 58SoapyServerListener::accept([::ffff:192.168.0.180]:20778)
) = 58
clone(child_stack=0x7f436ec31bb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f436ec329d0, tls=0x7f436ec32700, child_tidptr=0x7f436ec329d0) = 28373
write(1, "SoapyServerListener::close()\n", 29SoapyServerListener::close()
) = 29
close(6)                                = 0
write(1, "SoapyServerListener::close()\n", 29SoapyServerListener::close()
) = 29
close(7)                                = 0
select(4, [3], NULL, NULL, {0, 50000})  = 1 (in [3], left {0, 44207})
accept(3, {sa_family=AF_INET6, sin6_port=htons(20779), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 6
setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(6, SOL_TCP, TCP_QUICKACK, [1], 4) = 0
getpeername(6, {sa_family=AF_INET6, sin6_port=htons(20779), inet_pton(AF_INET6, "::ffff:192.168.0.180", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
write(1, "SoapyServerListener::accept([::f"..., 58SoapyServerListener::accept([::ffff:192.168.0.180]:20779)
) = 58
clone(child_stack=0x7f436e430bb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f436e4319d0, tls=0x7f436e431700, child_tidptr=0x7f436e4319d0) = 28374
select(4, [3], NULL, NULL, {0, 50000} <unfinished ...>
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
karl@mini:~$

Not sure if this is a SoapyRemote or SoapySDRPlay issue; but it appears when using SoapySDRPlay remotely that upon initialization readStream() is being called before activateStream() has been called.

Most notably on OSX it shows:

mir_sdr_ReadPacket: called before mir_sdr_Init()

and on Linux:

libusb_claim_interface() - 6 error:  interface has already been claimed

running SoapySDRUtil --make works fine.

SoapySDRPlay also initializes the device during enumeration to tell if it's there; not sure if that would be a factor here?

The writeStream() call will timeout when the window is nearly full, even if there is actually space. This is because the flow control update rate may be slower than the timeout specified.

Using the Osmocom source block with Soapy Remote, I sometimes get a segfault:

Here is what GNUradio says:

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8.1
built-in source types: file fcd rtl_tcp sdrplay rfspace soapy redpitaya 
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS16, localFormat=CF32, scaleFactor=32767, mtu=1500, window=44040192)
[INFO] Client side stream bound to <CLIENT's IP>:47903
[INFO] Client side status bound to <CLIENT's IP>:45892
[INFO] Using format CS16.
[INFO] Server side stream bound to [::ffff:<SERVER's IP>]:48810
[INFO] Server side stream connected to [::ffff:<CLIENT's IP>]:47903
[INFO] Server side status connected to [::ffff:<CLIENT's IP>]:45892
[INFO] Configured sender endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=43008 KiB
[INFO] Client side stream connected to <SERVER's IP>:48810
[INFO] Configured receiver endpoint: dgram=1452 bytes, 357 elements @ 4 bytes, window=43008 KiB
�[1m�[33m[WARNING] Set thread priority 0.5 failed: Operation not permitted�[0m
Using Volk machine: avx_64_mmx_orc
�[1m�[31m[ERROR] SoapyLogAcceptor::handlerLoop() �[0m
thread[thread-per-block[0]: <block soapy_source_c (2)>]: SoapyRPCUnpacker::recv(header) FAIL: 

Here is what the remote server running SoapySDRServer says right before it segfaults:

mir_sdr_usb_GetDevices Dev0:vid=1df7 pid=2500 rev=0206 serno=B0001P0004 bus=001 port=004 devAvail=1
mir_sdr_usb_SetDeviceIdx idx=0 numDevices=1
Opened device with idVendor = 0x1df7 idProduct = 0x2500 fwVersion = 0x0206 busNum = 001 portNum = 004
mir_sdr_DCoffsetIQimbalanceControl: DC:1 IQ:1
mir_sdr_AgcControl: 1 -30 0 0 0 0 1
mir_sdr_StreamInit()
mir_sdr_Init: starting hardware initialization
mir_sdr_Init: gR=20dB fs=7.000MHz rf=479.000MHz bw=6.000MHz if=0.000MHz
DownConvert: Enable=0 DecM=1 OutScale=0 (fs=7.000000 bw=6000 if=0)
mir_sdr_usb_USB DLL: Revision 0.1.1
mir_sdr_2500_Init: fnaddr = 2 detected, trying to change...
mir_sdr_2500_Init: fnaddr = 6
mir_sdr_2500_Init: adjusting squelch trim 0x1, rx gating enable 1, tx_trim 0, reg2 = 0x4801
initHw: Register7 = 0x000085
initRfFreqDependentHw(1): Tuner Register0 = 0x057480
Error: libusb_submit_transfer() -1
mir_sdr_2500_StreamInit: Open failed
initHw: mir_sdr_2500_StreamInit() Error 0x00000001
mir_sdr_Init: initHw returns error 7

Is this because the server cannot keep up with the requested sample rate?

if SoapyRPCSocket::close() fail, then this->lastErrorMsg() return an empty string.

how about SOCKET_ERRNO?

        SoapySDR::logf(SOAPY_SDR_ERROR, "SoapyRPCSocket::~SoapyRPCSocket: %d", SOCKET_ERRNO);

I use SoapyRemote to connect a GNU Radio flow graph to an USRP X310. When using high sampling rates (i.e. 40MHz), SoapySDRServer will terminate after terminating the GNU Radio flow graph with the output SoapyServerListener::handlerLoop() FAIL: (sometimes there are additional error messages).

Running the server in gdb gives the following debug information:

SoapyServerListener::handlerLoop() FAIL: SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL:
SoapyRPCUnpacker::recv(header) FAIL:
[Thread 0x7fffddd94700 (LWP 28118) exited]

Thread 37 "SoapySDRServer" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffc4ff9700 (LWP 28127)]
0x00007ffff70c99ff in __libc_send (fd=7, buf=0x7fffbc000b60, n=94, flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26
26      ../sysdeps/unix/sysv/linux/x86_64/send.c: No such file or directory.
(gdb) bt
#0  0x00007ffff70c99ff in __libc_send (fd=7, buf=0x7fffbc000b60, n=94, flags=flags@entry=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26
#1  0x0000000000417c75 in SoapyRPCSocket::send (this=0x6420d0, buf=<optimized out>, len=<optimized out>, flags=flags@entry=0) at /home/FE/schaeufele/pybombs/default/src/soapyremote/common/SoapyRPCSocket.cpp:418
#2  0x000000000041a761 in SoapyRPCPacker::send (this=this@entry=0x7fffc4ff88b0) at /home/FE/schaeufele/pybombs/default/src/soapyremote/common/SoapyRPCPacker.cpp:55
#3  0x0000000000414979 in SoapyRPCPacker::operator() (this=0x7fffc4ff88b0) at /home/FE/schaeufele/pybombs/default/src/soapyremote/common/SoapyRPCPacker.hpp:28
#4  handleLogMessage (logLevel=<optimized out>, message=<optimized out>) at /home/FE/schaeufele/pybombs/default/src/soapyremote/server/LogForwarding.cpp:33
#5  0x00007ffff7bc69d5 in SoapySDR_vlogf(SoapySDRLogLevel, const char *, typedef __va_list_tag __va_list_tag *) (logLevel=SOAPY_SDR_ERROR, format=<optimized out>, argList=argList@entry=0x7fffc4ff8960)
    at /home/FE/schaeufele/pybombs/default/src/soapysdr/lib/LoggerC.cpp:101
#6  0x00007ffff7ba8995 in SoapySDR::vlogf (logLevel=<optimized out>, format=<optimized out>, argList=argList@entry=0x7fffc4ff8960) at /home/FE/schaeufele/pybombs/default/src/soapysdr/lib/Logger.cpp:13
#7  0x000000000041e324 in SoapySDR::logf (logLevel=logLevel@entry=SOAPY_SDR_ERROR, format=format@entry=0x427678 "StreamEndpoint::releaseSend(), FAILED %s") at /home/FE/schaeufele/pybombs/default/include/SoapySDR/Logger.hpp:47
#8  0x000000000041eb21 in SoapyStreamEndpoint::releaseSend (this=0x7fffec472d50, handle=<optimized out>, numElemsOrErr=numElemsOrErr@entry=357, flags=@0x7fffc4ff8a98: 36, timeNs=<optimized out>)
    at /home/FE/schaeufele/pybombs/default/src/soapyremote/common/SoapyStreamEndpoint.cpp:336
#9  0x00000000004151c7 in ServerStreamData::sendEndpointWork (this=0x7fffec472ad8) at /home/FE/schaeufele/pybombs/default/src/soapyremote/server/ServerStreamData.cpp:216
#10 0x00007ffff78adc80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff70c06ba in start_thread (arg=0x7fffc4ff9700) at pthread_create.c:333
#12 0x00007ffff6df641d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I use UHD-3.13 and otherwise the newest versions available in PyBOMBS.

Adding the MSG_NOSIGNAL flag to the send call seems to fix this issue, I will add a PR shortly.

Took me stupid amount of time to figure out how to pass "remote:X" parameters with setupStream.
I have made 2 changes to the wiki.

@guruofquality do you get notifications when wiki is edited? I was quite surprised that my edits went straight to live...i meant them more as a pull-request that you could approve/disapprove.

OSX Mojave 10.14.3 (18D109)
brew 2.0.4 install as per https://github.com/pothosware/homebrew-pothos/wiki

SoapyRemote not yet installed:

BigMac-1978:~ mah$ SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.1-release
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libLMS7Support.so   (19.01.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libRedPitaya.so     (0.1.1)
Module found: /usr/local/lib/SoapySDR/modules0.7/libaudioSupport.so  (0.1.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so (0.3.0)
Available factories... audio, lime, redpitaya, rtlsdr
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

BigMac-1978:~ mah$ SoapySDRUtil --find
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

usb_claim_interface error -3
Found device 0
  default_input = False
  default_output = False
  device_id = 0
  driver = audio
  label = Apple Inc.: Built-in Microphone

Found device 1
  default_input = True
  default_output = True
  device_id = 3
  driver = audio
  label = Apple Inc.: Display Audio

Found device 2
  default_input = False
  default_output = False
  device_id = 4
  driver = audio
  label = Apple Inc.: Display Audio

Found device 3
  addr = 24607:1027
  driver = lime
  label = LimeSDR Mini [USB 3.0] 1D4259286F76A8
  media = USB 3.0
  module = FT601
  name = LimeSDR Mini
  serial = 1D4259286F76A8

Found device 4
  available = No
  driver = rtlsdr
  label = Generic RTL2832U OEM :: 10000816
  manufacturer = Realtek
  product = RTL2838UHIDIR
  rtl = 0
  serial = 10000816
  tuner =

After brew install soapyremote (or install from source at a6fbf2d , no difference):

BigMac-1978:~ mah$ SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.1-release
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libLMS7Support.so   (19.01.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libRedPitaya.so     (0.1.1)
Module found: /usr/local/lib/SoapySDR/modules0.7/libaudioSupport.so  (0.1.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so (0.5.1)     <------
Module found: /usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so (0.3.0)
Available factories... audio, lime, redpitaya, remote, rtlsdr
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]


BigMac-1978:~ mah$ SoapySDRUtil --find
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found Rafael Micro R820T tuner
<  hang>

Running lldb on the hanging SoapySDRUtil process:

BigMac-1978:~ mah$ lldb -p 8878
(lldb) process attach --pid 8878
Process 8878 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff614727de libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait:
->  0x7fff614727de <+10>: jae    0x7fff614727e8            ; <+20>
    0x7fff614727e0 <+12>: movq   %rax, %rdi
    0x7fff614727e3 <+15>: jmp    0x7fff6146f3b7            ; cerror_nocancel
    0x7fff614727e8 <+20>: retq
Target 0: (SoapySDRUtil) stopped.

Executable module set to "/usr/local/bin/SoapySDRUtil".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff614727de libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff6152c593 libsystem_pthread.dylib`_pthread_cond_wait + 724
    frame #2: 0x00007fff5ea0abda libc++.1.dylib`std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 18
    frame #3: 0x00007fff5ea13d7c libc++.1.dylib`std::__1::__assoc_sub_state::__sub_wait(std::__1::unique_lock<std::__1::mutex>&) + 46
    frame #4: 0x000000010f4c463a libSoapySDR.0.7.dylib`std::__1::__assoc_state<std::__1::vector<std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >, std::__1::allocator<std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > > > >::copy() + 48
    frame #5: 0x000000010f4c07a0 libSoapySDR.0.7.dylib`SoapySDR::Device::enumerate(std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > const&) + 1360
    frame #6: 0x000000010f4c1001 libSoapySDR.0.7.dylib`SoapySDR::Device::enumerate(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 37
    frame #7: 0x000000010f4a4988 SoapySDRUtil`main + 3560
    frame #8: 0x00007fff61335ed9 libdyld.dylib`start + 1
(lldb)

I can try with a debug build to get a better backtrace if needed

Michael

Is there a way to configure it to use a little bandwidth?
My rtl got its lower sample limit 250000hz so thats like 5mbits
Is there a way to configure soapyremot to filter that upstream to send 50khz only?

I have multiple SDRs attached to a dedicated SoapySDRServer on my LAN, however clients show identical names for all attached devices.

It would be useful to be able to specify a user defined names for each SDR by USB bus/dev identifiers.

Multicast discovery means that the device enumeration routine can discover devices without an explicit addresses specified.

https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol

I've written a module for FUNcube Dongle Pro Plus:
https://github.com/ast/SoapyFCDPP/
Primarily for remote operation via a Raspberry Pi 3.

I'm facing a problem where I experience lag in the sample stream whenever I change center frequency or some other hardware property of the FCDpp. The FCDpp is controlled via HID messages using libhidapi and is not super quick. I get the feeling the setFrequency etc is called from the same thread as the sample streaming thread, or there is some locking involved.

Another possible, more depressing, cause is that both samples, network and control is over the Raspberry Pi's USB bus...

I'm posting this issue and will also try to investigate the cause.

Although we try to set the window size to be the same at both endpoints, because of system limitations, only one endpoint socket buffer may get increased. This messes with the flow control. The flow control window should be the std::min(sendWindow, recvWindow).

@guruofquality can you suggest a way to customise the port when starting the server via systemd?

@npaisnel is looking for this to autostart on RPi - the Odroid headless images I've produced all use the default port.

Thanks,

Andy.

It mainly complains about -lthr not being present in the linker invocation.

-- The CXX compiler identification is Clang 6.0.0
-- The C compiler identification is Clang 6.0.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Looking for include file winsock2.h
-- Looking for include file winsock2.h - not found
-- Looking for include file ws2tcpip.h
-- Looking for include file ws2tcpip.h - not found
-- Looking for include file netdb.h
-- Looking for include file netdb.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file netinet/in.h
-- Looking for include file netinet/in.h - found
-- Looking for include file netinet/tcp.h
-- Looking for include file netinet/tcp.h - found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - found
-- Looking for include file sys/socket.h
-- Looking for include file sys/socket.h - found
-- Looking for include file arpa/inet.h
-- Looking for include file arpa/inet.h - found
-- Looking for include file ifaddrs.h
-- Looking for include file ifaddrs.h - found
-- Looking for include file net/if.h
-- Looking for include file net/if.h - found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
-- Found Avahi: /usr/local/lib/libavahi-common.so
-- AVAHI_INCLUDE_DIRS=/usr/local/include
-- AVAHI_LIBRARIES=/usr/local/lib/libavahi-common.so;/usr/local/lib/libavahi-client.so
-- Module remoteSupport configured with version: 0.5.0
-- SoapyRemote version: v0.5.0-unknown
-- Install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mar/sdr/SoapyRemote-soapy-remote-0.5.0/build
[mar@impure ~/sdr/SoapyRemote-soapy-remote-0.5.0/build]$ make
Scanning dependencies of target SoapySDRRemoteCommon
[ 3%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyURLUtils.cpp.o
[ 7%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCSocket.cpp.o
[ 11%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCPacker.cpp.o
[ 14%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCUnpacker.cpp.o
[ 18%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyStreamEndpoint.cpp.o
[ 22%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyHTTPUtils.cpp.o
[ 25%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapySSDPEndpoint.cpp.o
[ 29%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyIfAddrs.cpp.o
[ 33%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyIfAddrsUnix.cpp.o
[ 37%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyInfoUtils.cpp.o
[ 40%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyMDNSEndpointAvahi.cpp.o
[ 44%] Linking CXX static library libSoapySDRRemoteCommon.a
[ 44%] Built target SoapySDRRemoteCommon
Scanning dependencies of target remoteSupport
[ 48%] Building CXX object client/CMakeFiles/remoteSupport.dir/Registration.cpp.o
[ 51%] Building CXX object client/CMakeFiles/remoteSupport.dir/Settings.cpp.o
[ 55%] Building CXX object client/CMakeFiles/remoteSupport.dir/Streaming.cpp.o
[ 59%] Building CXX object client/CMakeFiles/remoteSupport.dir/LogAcceptor.cpp.o
[ 62%] Building CXX object client/CMakeFiles/remoteSupport.dir/ClientStreamData.cpp.o
[ 66%] Building CXX object client/CMakeFiles/remoteSupport.dir/DiscoverServers.cpp.o
[ 70%] Building CXX object client/CMakeFiles/remoteSupport.dir/Version.cpp.o
[ 74%] Linking CXX shared module libremoteSupport.so
[ 74%] Built target remoteSupport
Scanning dependencies of target SoapySDRServer
[ 77%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/ThreadPrioUnix.cpp.o
[ 81%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/SoapyServer.cpp.o
[ 85%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/ServerListener.cpp.o
[ 88%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/ClientHandler.cpp.o
[ 92%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/LogForwarding.cpp.o
[ 96%] Building CXX object server/CMakeFiles/SoapySDRServer.dir/ServerStreamData.cpp.o
[100%] Linking CXX executable SoapySDRServer
/usr/bin/ld: undefined reference to symbol `pthread_create@@FBSD_1.0' (try adding -lthr)
//lib/libthr.so.3: could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)

This is aside from this error which I hit in the past five(!) tagged versions downloaded, across five different compilers. How the hell does this build on linux?!

Scanning dependencies of target SoapySDRRemoteCommon
[ 3%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyURLUtils.cpp.o
[ 7%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCSocket.cpp.o
/home/mar/sdr/SoapyRemote-soapy-remote-0.5.0/common/SoapyRPCSocket.cpp:503:12: error: no viable conversion from returned value of type 'int' to function return type 'std::string'
(aka 'basic_string<char, char_traits, allocator >')
return strerror_r(err, buff, sizeof(buff));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/string:767:5: note: candidate constructor not viable: no known conversion from 'int' to 'const std::__1::basic_string &' for 1st argument
basic_string(const basic_string& __str);
^
/usr/include/c++/v1/string:772:5: note: candidate constructor not viable: no known conversion from 'int' to 'std::__1::basic_string &&' for 1st argument
basic_string(basic_string&& __str)
^
/usr/include/c++/v1/string:782:31: note: candidate constructor not viable: no known conversion from 'int' to 'const char ' for 1st argument
_LIBCPP_INLINE_VISIBILITY basic_string(const _CharT __s);
^
/usr/include/c++/v1/string:815:5: note: candidate constructor not viable: no known conversion from 'int' to 'initializer_list' for 1st argument
basic_string(initializer_list<_CharT> __il);
^
1 error generated.

I am able to find and probe SoapyRemote from a client, but when I install soapy_power on that client it will not connect and says that SoapySDR does not exist....which it does,. How have others been able to use soapy_power with a SoapyRemote server?

I'm not sure how/what libraries or DLLs this remoteSupport is supposed to generate. I'm on Windows and try to create only .DLLs for SoapySDR. If compiling with -DSOAPY_REMOTE_DLL, I get these missing symbols while linking SoapySDRserver.exe:

SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapySSDPEndpoint::SoapySSDPEndpoint(void)" (??0SoapySSDPEndpoint@@QAE@XZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapySSDPEndpoint::~SoapySSDPEndpoint(void)" (??1SoapySSDPEndpoint@@QAE@XZ) referenced in function "public: void * __thiscall SoapySSDPEndpoint::`scalar deleting destructor'(unsigned int)" (??_GSoapySSDPEndpoint@@QAEPAXI@Z)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapySSDPEndpoint::registerService(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?registerService@SoapySSDPEndpoint@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0H@Z) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapyMDNSEndpoint::SoapyMDNSEndpoint(void)" (??0SoapyMDNSEndpoint@@QAE@XZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: __thiscall SoapyMDNSEndpoint::~SoapyMDNSEndpoint(void)" (??1SoapyMDNSEndpoint@@QAE@XZ) referenced in function "public: void * __thiscall SoapyMDNSEndpoint::`scalar deleting destructor'(unsigned int)" (??_GSoapyMDNSEndpoint@@QAEPAXI@Z)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapyMDNSEndpoint::printInfo(void)" (?printInfo@SoapyMDNSEndpoint@@QAEXXZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: bool __thiscall SoapyMDNSEndpoint::status(void)" (?status@SoapyMDNSEndpoint@@QAE_NXZ) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)
SoapyServer.obj : error LNK2019: unresolved external symbol "public: void __thiscall SoapyMDNSEndpoint::registerService(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,int)" (?registerService@SoapyMDNSEndpoint@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0H@Z) referenced in function "int __cdecl runServer(void)" (?runServer@@YAHXZ)

I think this patch fixes it, but I'm really over my head here:

--- a/common/SoapyMDNSEndpoint.hpp 2018-02-15 13:55:45
+++ b/common/SoapyMDNSEndpoint.hpp 2018-02-15 20:53:32
@@ -2,6 +2,7 @@
 // SPDX-License-Identifier: BSL-1.0

 #pragma once
+#include "SoapyRemoteConfig.hpp"
 #include <string>
 #include <map>

@@ -16,7 +17,7 @@
  * Used for both server side for publishing,
  * and the client side for browsing/lookup.
  */
-class SoapyMDNSEndpoint
+class SOAPY_REMOTE_API SoapyMDNSEndpoint
 {
 public:

--- a/common/SoapySSDPEndpoint.hpp 2018-02-15 13:55:45
+++ b/common/SoapySSDPEndpoint.hpp 2018-02-15 20:53:24
@@ -2,6 +2,7 @@
 // SPDX-License-Identifier: BSL-1.0

 #pragma once
+#include "SoapyRemoteConfig.hpp"
 #include "SoapyRPCSocket.hpp"
 #include <string>
 #include <csignal> //sig_atomic_t
@@ -9,7 +10,7 @@
 #include <vector>
 #include <map>

-class SoapyHTTPHeader;
+class SOAPY_REMOTE_API SoapyHTTPHeader;
 struct SoapySSDPEndpointData;

 /*!
@@ -17,7 +18,7 @@
  * keep track of discovered servers of interest,
  * and to respond to discovery packets for us.
  */
-class SoapySSDPEndpoint
+class SOAPY_REMOTE_API SoapySSDPEndpoint
 {
 public:

PS. I see not way the Cmake-system can set -DSOAPY_REMOTE_DLL + -DSOAPY_REMOTE_DLL_EXPORTS. An oversight?

https://github.com/pothosware/SoapyRemote/wiki says "By default, the Soapy SDR server will bind to both IPv4 and IPv6 by default". Running SoapySDRServer --bind I find that clients are aware of the presence of the server on the network but can't connect to it:

[ERROR] SoapyRemote::find() -- connect(tcp://192.168.1.3:55132) FAIL: connect(tcp://192.168.1.3:55132) [111: Connection refused]

Looking at lsof, I see that SoapySDRServer is listening on 55132 but only on IPv6:

lsof -i -n | grep Soapy

SoapySDRS 9913 root 3u IPv6 73890223 0t0 TCP *:55132 (LISTEN)
SoapySDRS 9913 root 4u IPv4 73890225 0t0 UDP *:1900
SoapySDRS 9913 root 5u IPv6 73890226 0t0 UDP *:1900

It is listening on port 1900 on both v4 and v6 which is perhaps where the confusion [on the client side] is coming from.

If I run "SoapySDRServer --bind=192.168.1.3:55132" to specifically bind to the v4 address, it listens on specified IP:port [although it still listens on *:1900]:

lsof -i -n | grep Soapy

SoapySDRS 28621 root 3u IPv4 71829139 0t0 TCP 192.168.1.3:55132 (LISTEN)
SoapySDRS 28621 root 4u IPv4 71829141 0t0 UDP *:1900
SoapySDRS 28621 root 5u IPv6 71829142 0t0 UDP *:1900

and the client is able to connect to the discovered address.

I am not sure what the "real" problem is here; is the server sending its v4 address in the MDNS response, even though it's not actually listening on the v4 address? I don't think the server should be listening to MDNS on the v4 address if the server service isn't listening on the v4 address. I think the server should be listening on both ports on all IPs if no IP is passed to --bind.

I think the server should honour the --bind argument for both 1900 and 55132.

Hi,

I was trying to remotely operate an SDRplay, which would allow 10MHz bandwidth. At 2MHz channel bandwidth it runs very nice and smooth. But SoapyRemote doesn't seem to let a bigger bandwith through.
When a bigger Bandwidth in CubicSDR is selected, the signal appears like after a 2MHz bandpass filter.

To be more robust and cross platform compatible, we dont want to rely on ipv4 mapped ipv6 addresses. There should be two sockets bound to both IP stacks independently. Also the discovery advertisements need to the reflect which stacks are actually bound to.

• reference #59

Not sure what's up yet here; pulled and rebuilt SoapySDR, SoapyRemote and SoapyRTLSDR on master branches at least twice on Pi and OSX plus CubicSDR as well -- Might just be something simple I've overlooked though.

CubicSDR log shows:

Enumerating remote address: raspberrypi.local
  available = Yes
  driver = remote
  label = Generic RTL2832U OEM :: 00000003
  manufacturer = Realtek
  product = RTL2838UHIDIR
  remote = tcp://raspberrypi.local:55132
  remote:driver = rtlsdr
  rtl = 0
  serial = 00000003
  tuner = Rafael Micro R820T
Make device 0
  origin=https://github.com/pothosware/SoapyRTLSDR
  rtl=0
Error making device: RemoteError: SoapyClientHandler::handleOnce(306) unknown call
Reporting enumeration complete.
SDR enumerator done.
�[1m�[31m[ERROR] ~SoapyRPCUnpacker: Unconsumed payload bytes 7�[0m

Pi side shows:

######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

upid://raspberrypi?pid=3036&hid=8323329
Launching the server... tcp://0.0.0.0:55132
Server bound to 0.0.0.0:55132
Press Ctrl+C to stop the server
SoapyServerListener::accept(192.168.1.102:51011)
SoapyServerListener::accept(192.168.1.102:51012)
Found Rafael Micro R820T tuner
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.102:51013)
SoapyServerListener::accept(192.168.1.102:51014)
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.102:51015)
SoapyServerListener::accept(192.168.1.102:51016)
Found Rafael Micro R820T tuner
SoapyServerListener::close()
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL: No data available
SoapyServerListener::close()

Thanks!

With current release, a timeout error appears that did not appear in previous release; behavior is different depending on whether the host, a Raspberry Pi 3 (yeah, I know), is running Raspian (in which case at least the connection succeeds) or openSUSE (in which case it does not).

..................................................................................................................................

Raspian:

[server]
$ SoapySDRServer --bind
7701212d-a2ea-14cc-8567-0325007f0101
Launching the server... tcp://[::]:55132
Server bound to [::]:55132
Launching discovery server...
Press Ctrl+C to stop the server
SoapyServerListener::accept([::ffff:192.168.1.9]:50506)
SoapyServerListener::accept([::ffff:192.168.1.9]:50507)
SoapyServerListener::accept([::ffff:192.168.1.9]:50508)
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept([::ffff:192.168.1.9]:50509)
SoapyServerListener::close()
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL:
SoapyServerListener::close()

[client]
$ SoapySDRUtil --probe="remote=192.168.1.10"
Probe device remote=192.168.1.10
[INFO] Make connection: 'LimeSDR-USB [USB 2.0] 9060B00472212'
[INFO] Estimated reference clock 30.7198 MHz
[INFO] Selected reference clock 30.720 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] Init LMS7002M(0)
[INFO] LMS7002M cache /home/pi/.limesuite/LMS7002M_cache_values.db
[INFO] Ver=7, Rev=1, Mask=1
[INFO] LMS7002M calibration values caching Enable
Error probing device: SoapyRPCUnpacker::recv() TIMEOUT:

..................................................................................................................................

openSUSE:

[server]
$ SoapySDRServer --bind
79ac27fb-a35e-14cc-8567-04ada8c00a01
Launching the server... tcp://[::]:55132
Server bound to [::]:55132
Launching discovery server...
Press Ctrl+C to stop the server
SoapyServerListener::accept([::ffff:192.168.1.9]:50542)
[ERROR] ~SoapyRPCUnpacker: Unconsumed payload bytes -4
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL:
SoapyServerListener::close()

[client]
$ SoapySDRUtil --probe="remote=192.168.1.10"
Probe device remote=192.168.1.10
[ERROR] SoapyRemote::find() -- connect(tcp://192.168.1.10:55132) FAIL: connect(tcp://192.168.1.10:55132) [110: Connection timed out]
[INFO] Make connection: ''
Error probing device: Failed to make connection with ''

• https://github.com/pothosware/PothosSDR/wiki

Because the link is over UDP, its natural to expect drops and reordering. The acquireRecv() implementation should detect this by dropping out of order-packets and reporting overflow/drop on these events so the caller can respond to the discontinuity.

Some of the recent fixes to implement connect timeouts properly have left the logger sometimes not connecting due to timeout. The logger should probably be given a longer connection timeout assuming the client just connected the primary socket and if not, it could retry as well.

SSDP picks the default interface, but to work on a multi-network system. it may need to bind and join on each socket per interface. And send and receive on each on. Investigate further.

This should be possible to set on install via config file for sysctl limits stuff. Add limit settings with installed config file and also run the following on install so we dont need to reboot to get the new limits:

sudo sysctl -w net.core.rmem_max=104857600
sudo sysctl -w net.core.wmem_max=104857600

I'm not sure if that's an issue in soapy remote, or just strange parameters, but I can't seem to get more than 1Msps without stutter. Some information:

Transferring RPi -> linux over wifi.
IPerf says I can do 2.5 MB/s on tcp, I can send 3 MB/s on udp without packet drops. (1 reorder over a minute of testing)

Both sides use recent versions: SoapyRemote 0.2.0, SDR 0.4.1, RTLSDR 0.2.0 (nothing relevant changed in git since then)

At 1Msps, I get a really good reception both with standard parameters and with those mentioned at the end of issue #9, but still get a few "S"es in the logging output. At any higher sampling rate, I get really choppy sound (listening to fm radio over cubicsdr) and start getting "SOOSOOOSOOSOSOO...". rtl_test is happy up to 2.6Msps without samples lost, so it looks like the receiver should be fine.

With CS8 format, I'm expecting at least 2Msps to be possible without issues, but it doesn't seem to work well.

I'm using SoapySDRServer with a somewhat unstable client.

• server: Pluto device, from https://github.com/unixpunk/PlutoWeb [Dual Cortex-A9, Xilinx Zynq Platform]
• client: soapy_power, from https://github.com/xmikos/soapy_power

On regular basis, the soapy_power client which is forked from a parent process keeps running when I expect it to stop. I simply kill it (kill -9).

Whenever the client is killed, the SoapySDRServer dies immediately, with the following traces:

startup traces:

######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

Server version: 0.5.0-gfa71b4e2
Server UUID: 72f74595-126e-1000-8567-2664007f0101
Launching the server... tcp://0.0.0.0:55132
Server bound to 0.0.0.0:55132
Launching discovery server...
[WARNING] SoapySSDPEndpoint failed join group udp://239.255.255.250:1900
  setsockopt(IP_ADD_MEMBERSHIP) [19: No such device]
Connecting to DNS-SD daemon...
[INFO] Avahi version:  avahi 0.7
[INFO] Avahi hostname: pluto
[INFO] Avahi domain:   local
[INFO] Avahi FQDN:     pluto.local
[INFO] avahi_entry_group_add_service(pluto._soapy._tcp)
Press Ctrl+C to stop the server

Client connection traces

SoapyServerListener::accept(192.168.2.10:57389)
SoapyServerListener::accept(192.168.2.10:57390)
SoapyServerListener::close()
SoapyServerListener::accept(192.168.2.10:57391)

Client killed traces

SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL:
SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL:
terminate called without an active exception
Aborted

Although the client should be fixed, I believe the server should not died when the client is killed.

Let me know if you need more details.

Hello,
Thank you for this great software.
It does not seem possible to set a frequency correction in PPM from the client and the driver arguments. It's also not possible to do it on the server side.
Maybe it should be implemented somewhere ?

Thank you
J

I took a quick look and didn't see any compression options for the network data... Would it be possible to integrate something like FastLZ as a compressed stream option?

Following this procedure to install SDRplay and CubicSDR on a 32bit Ubuntu 14.04 system:

http://www.sdrplay.com/docs/SDRplay_non_Windows_Flow.pdf

I get the following error when running:

$ SoapySDRUtil --find=sdrplay
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.002.000-release

[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.6/libremoteSupport.so)
  duplicate entry for remote (/usr/lib/i386-linux-gnu/SoapySDR/modules0.6/libremoteSupport.so)
Found device 0
  driver = miri
  label = Mirics MSi2500 default (e.g. VTX3D card)
  miri = 0

There are two copies of Soapyremote. One was installed from the repository. But I could not get CubicSDR to complie unless I also installed Soapy from Github. Is there a way that I can specify which Soapy should be used with SDRplay? If I try to uninstall the version of Soapy from the repository then it wants to uninstall most of the other SDR software that I installed from the repo. Seems a bit strange that it errors when it finds more than one, I would think that it should just use the first one it finds. I still get the error when I am using RTLSDR. So I assume it is defaulting to the repo version that does not have SDRplay support. Is there a way that I can specify which Soapy should be used?

I get an issue while building SoapyRemote on Alpine Linux 3.8 X86_64.

alpine:~/SoapyRemote/build# cmake ..
-- The CXX compiler identification is GNU 8.2.0
-- The C compiler identification is GNU 8.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Performing Test HAS_STD_CXX11
-- Performing Test HAS_STD_CXX11 - Success
-- Looking for include file winsock2.h
-- Looking for include file winsock2.h - not found
-- Looking for include file ws2tcpip.h
-- Looking for include file ws2tcpip.h - not found
-- Looking for include file netdb.h
-- Looking for include file netdb.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file netinet/in.h
-- Looking for include file netinet/in.h - found
-- Looking for include file netinet/tcp.h
-- Looking for include file netinet/tcp.h - found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - found
-- Looking for include file sys/socket.h
-- Looking for include file sys/socket.h - found
-- Looking for include file arpa/inet.h
-- Looking for include file arpa/inet.h - found
-- Looking for include file ifaddrs.h
-- Looking for include file ifaddrs.h - found
-- Looking for include file net/if.h
-- Looking for include file net/if.h - found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
-- Found Avahi: /usr/lib/libavahi-common.so
-- AVAHI_INCLUDE_DIRS=/usr/include
-- AVAHI_LIBRARIES=/usr/lib/libavahi-common.so;/usr/lib/libavahi-client.so
-- Found Git: /usr/bin/git (found version "2.20.1")
-- Module remoteSupport configured with version: 0.5.1-5a647db
-- SoapyRemote version: v0.5.1-g5a647db9
-- Install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /root/SoapyRemote/build

Then

alpine:~/SoapyRemote/build# make
Scanning dependencies of target SoapySDRRemoteCommon
[ 3%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyURLUtils.cpp.o
[ 7%] Building CXX object common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCSocket.cpp.o
/root/SoapyRemote/common/SoapyRPCSocket.cpp: In function 'std::__cxx11::string errToString(int)':
/root/SoapyRemote/common/SoapyRPCSocket.cpp:503:22: error: could not convert 'strerror_r(((int)err), ((char*)(& buff)), sizeof (buff))' from 'int' to 'std::__cxx11::string' {aka 'std::__cxx11::basic_string'}
return strerror_r(err, buff, sizeof(buff));
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [common/CMakeFiles/SoapySDRRemoteCommon.dir/build.make:76: common/CMakeFiles/SoapySDRRemoteCommon.dir/SoapyRPCSocket.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:91: common/CMakeFiles/SoapySDRRemoteCommon.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

I don't know what is the problem.

I used to build on Ubuntu without errors.

Do you have an idea to fix this ?

• https://launchpad.net/~myriadrf/+archive/ubuntu/drivers
• or snapshots if we dont have a 0.3 release of SoapySDR --
  • https://launchpad.net/~myriadrf/+archive/ubuntu/drivers-snapshots

Server is Ubuntu 14.04 32 bits
Client is CubicSDR on OSX 10.10.5

All latest manual builds.

SDR thread starting.
device init()
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS8, localFormat=CF32, scaleFactor=128, mtu=8192, window=16384000)
[INFO] Client side stream bound to 192.168.1.21:54160
[INFO] Client side status bound to 192.168.1.21:54160
[INFO] Using format CS8.
[INFO] Client side stream connected to 192.168.1.19:59808
[ERROR] StreamEndpoint resize socket buffer FAIL: setsockopt(SO_RCVBUF) [55: No buffer space available]
[INFO] Configured receiver endpoint: dgram=8144 bytes, 4060 elements @ 2 bytes, window=16000 KiB
[INFO] Server side stream bound to 192.168.1.19:59808
[INFO] Server side stream connected to 192.168.1.21:54160
[INFO] Server side status connected to 192.168.1.21:56720
[WARNING] StreamEndpoint resize socket buffer: set 16384000 bytes, got 1048576 bytes
[INFO] Configured sender endpoint: dgram=8144 bytes, 4060 elements @ 2 bytes, window=1024 KiB
[WARNING] Set thread priority 0.5 failed: Operation not permitted
Calculated optimal 6 channel element count of 85338
starting readLoop()
Calculated optimal 6 channel element count of 42666
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Investigate possible lockup in osx discovery with their MDNS API.

• reference pothosware/SoapyHackRF#22

I think that the unpn daemon might be able to see the endpoints advertised by SSDP, that way we can talk to the daemon which has been sitting around and watching the network rather than opening a new SSDP endpoint and waiting for it to discover.

• docs https://msdn.microsoft.com/en-us/library/windows/desktop/aa382297(v=vs.85).aspx

Just trying out SoapyRTLSDR and SoapyRemote on a Raspberry Pi here, few items to note:

• -std-c++11 in CMakeLists.txt isn't valid for GCC 4.6.3 on current Raspbian, -std-c++0x seems to work everywhere
• SoapySDRServer --bind doesn't seem to work alone; just outputs the following with no reason after the 'FAIL: ':

pi@raspberrypi ~/SoapyRemote/build $ SoapySDRServer --bind
######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

upid://raspberrypi?pid=5198&hid=8323329
Launching the server... tcp://[::]:55132
Server socket bind FAIL: 

Running it with a specific bind parameter seems to work:

pi@raspberrypi ~/SoapyRemote/build $ SoapySDRServer --bind="0.0.0.0:55132"
######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

upid://raspberrypi?pid=5202&hid=8323329
Launching the server... tcp://0.0.0.0:55132
Server bound to 0.0.0.0:55132
Press Ctrl+C to stop the server

I have error installaing SoapyRemote.
Raspberry Pi 3 Model B.
Raspbian GNU/Linux 9.3 (stretch)

Can you help me please?

pi@raspberrypi:~/SoapyRemote/build$ cmake ..
-- Build type not specified: defaulting to release.
CMake Warning at CMakeLists.txt:15 (find_package):
Could not find a package configuration file provided by "SoapySDR"
(requested version 0.4.0) with any of the following names:

SoapySDRConfig.cmake
soapysdr-config.cmake

Add the installation prefix of "SoapySDR" to CMAKE_PREFIX_PATH or set
"SoapySDR_DIR" to a directory containing one of the above files. If
"SoapySDR" provides a separate development package or SDK, be sure it has
been installed.

CMake Error at client/CMakeLists.txt:4 (SOAPY_SDR_MODULE_UTIL):
Unknown CMake command "SOAPY_SDR_MODULE_UTIL".

SoapyRemote does't appear to be able to set it's own thread priority as it gives a warning

[WARNING] Set thread priority 0.5 failed: Operation not permitted

If the Server is run as root then warning goes away.

Calls to implement:

• getFrequencyArgsInfo()
• getStreamFormats()
• getNativeStreamFormat()
• getStreamArgsInfo()
• getSensorInfo()
• getSettingInfo()

In addition:

• Use getNativeStreamFormat() to select default format over the network, and scaling.

CMakeList version update:

• find_package(SoapySDR "0.4.0" NO_MODULE)

Related issue:

• pothosware/SoapySDR#37

The same server can be discovered under v4 and v6 addresses. A remote:ipType option would default to preferring ipv4, but can be configured to select only v4, prefer v6, or do only v6.

• Add remote:ipver to docs

Its possible to discover a device via SSDP that cannot be connected to. There should be a smaller timeout as to not lockup the discovery function.

When querying the device remotely (RTLSDR at least, I may have missed something in the module?), the only way I know it's an rtlsdr is by checking known parameters and the 'rtl' index key. It would be handy to automatically return the remote:driver and remote option as well; right now I just get driver=remote and if you pass it directly to make() it won't work without setting those two as well.

Use a form of windowing to speed up application of configuration settings for void return calls. This will be a non default option on the device constructor arguments:

A void return call is implemented like so:

    packer & args;
    ...etc...
    packer();

    SoapyRPCUnpacker unpacker(_sock);
}

Changes

A change in the SoapyRPCUnpacker with a shared state object will allow the unpacker to implement the windowed logic. The unpacker can decide to ack previous calls that were void 1) when the window length is reached, or 2) the call is a non-void return and we need the result:

    packer & args;
    ...etc...
    packer();

    SoapyRPCUnpacker unpacker(_asyncState, _sock);
}

Tasks

• [ ] Need optional args to set control window size (default 0)
• [ ] All unpacker calls need the state passed in
• [ ] Unpacker implements windowing algorithm
• [ ] Error handling when the async call returned an exception

First off, thanks for the work on this project, it should perfectly fit the bill for what I'm attempting. :) I'm looking for SoapyRemote to cross-compile for armv7,neon and I've gotten most of the way there. Once compiled, this would then be able to run ON a PlutoSDR, turning it into a fully remote SDR as it already support OTG eth and wifi out of the box. I've been successful with SoapySDR, SoapyPlutoSDR and rx_tools for Openwebrx so far. Any help or guidance is appreciated. During make, I'm getting the following:

[ 41%] Built target SoapySDRRemoteCommon Scanning dependencies of target remoteSupport [ 45%] Building CXX object client/CMakeFiles/remoteSupport.dir/Registration.cpp.o [ 50%] Building CXX object client/CMakeFiles/remoteSupport.dir/Settings.cpp.o [ 54%] Building CXX object client/CMakeFiles/remoteSupport.dir/Streaming.cpp.o [ 58%] Building CXX object client/CMakeFiles/remoteSupport.dir/LogAcceptor.cpp.o [ 62%] Building CXX object client/CMakeFiles/remoteSupport.dir/ClientStreamData.cpp.o [ 66%] Building CXX object client/CMakeFiles/remoteSupport.dir/Version.cpp.o [ 70%] Linking CXX shared module libremoteSupport.so CMakeFiles/remoteSupport.dir/Settings.cpp.o: In function `getGainRange': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Settings.cpp:544: undefined reference to `SoapySDR::Range::Range()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Settings.cpp:560: undefined reference to `SoapySDR::Range::Range()' CMakeFiles/remoteSupport.dir/Settings.cpp.o: In function `~SoapyRemoteDevice': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Settings.cpp:48: undefined reference to `SoapySDR::Device::~Device()' CMakeFiles/remoteSupport.dir/Settings.cpp.o: In function `getSensorInfo': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Settings.cpp:1011: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Settings.cpp:1056: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' CMakeFiles/remoteSupport.dir/Settings.cpp.o: In function `SoapyRemoteDevice': /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/basic_string.h:240: undefined reference to `SoapySDR::Device::~Device()' CMakeFiles/remoteSupport.dir/Settings.cpp.o: In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' CMakeFiles/remoteSupport.dir/Settings.cpp.o:(.data.rel.ro+0x1d4): undefined reference to `typeinfo for SoapySDR::Device' CMakeFiles/remoteSupport.dir/Streaming.cpp.o: In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' CMakeFiles/remoteSupport.dir/Streaming.cpp.o: In function `getStreamArgsInfo': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:78: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:87: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:95: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:104: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:113: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:119: undefined reference to `SoapySDR::Range::Range(double, double, double)' CMakeFiles/remoteSupport.dir/Streaming.cpp.o: In function `setupStream': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:157: undefined reference to `SoapySDR::formatToSize(std::string const&)' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Streaming.cpp:298: undefined reference to `SoapySDR::formatToSize(std::string const&)' CMakeFiles/remoteSupport.dir/LogAcceptor.cpp.o: In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' CMakeFiles/remoteSupport.dir/LogAcceptor.cpp.o: In function `handlerLoop': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/LogAcceptor.cpp:119: undefined reference to `SoapySDR::log(SoapySDRLogLevel, std::string const&)' /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/LogAcceptor.cpp:119: undefined reference to `SoapySDR::log(SoapySDRLogLevel, std::string const&)' ../common/libSoapySDRRemoteCommon.a(SoapyRPCUnpacker.cpp.o): In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' ../common/libSoapySDRRemoteCommon.a(SoapyRPCUnpacker.cpp.o): In function `operator&': /home/steve/Desktop/SDR/Pluto/SoapyRemote/common/SoapyRPCUnpacker.cpp:233: undefined reference to `SoapySDR::Range::Range(double, double, double)' ../common/libSoapySDRRemoteCommon.a(SoapyRPCUnpacker.cpp.o): In function `_Construct<SoapySDR::Range>': /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/stl_construct.h:75: undefined reference to `SoapySDR::Range::Range()' /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/stl_construct.h:75: undefined reference to `SoapySDR::Range::Range()' ../common/libSoapySDRRemoteCommon.a(SoapyRPCUnpacker.cpp.o): In function `_Construct<SoapySDR::ArgInfo>': /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/stl_construct.h:75: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/stl_construct.h:75: undefined reference to `SoapySDR::ArgInfo::ArgInfo()' ../common/libSoapySDRRemoteCommon.a(SoapySSDPEndpoint.cpp.o): In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' ../common/libSoapySDRRemoteCommon.a(SoapyMDNSEndpointAvahi.cpp.o): In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' CMakeFiles/remoteSupport.dir/Registration.cpp.o: In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' CMakeFiles/remoteSupport.dir/Registration.cpp.o: In function `__static_initialization_and_destruction_0': /home/steve/Desktop/SDR/Pluto/SoapyRemote/client/Registration.cpp:238: undefined reference to `SoapySDR::Registry::Registry(std::string const&, std::vector<std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > >, std::allocator<std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > > > (* const&)(std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&), SoapySDR::Device* (* const&)(std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > const&), std::string const&)' CMakeFiles/remoteSupport.dir/Registration.cpp.o: In function `_M_dispose': /opt/Xilinx/SDK/2016.4/gnu/arm/lin/arm-xilinx-linux-gnueabi/include/c++/4.9.2/bits/basic_string.h:240: undefined reference to `SoapySDR::Registry::~Registry()' CMakeFiles/remoteSupport.dir/Version.cpp.o: In function `__static_initialization_and_destruction_0': /home/steve/Desktop/SDR/Pluto/SoapyRemote/build/client/Version.cpp:2: undefined reference to `SoapySDR::ModuleVersion::ModuleVersion(std::string const&)' ../common/libSoapySDRRemoteCommon.a(SoapyRPCSocket.cpp.o): In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' ../common/libSoapySDRRemoteCommon.a(SoapyStreamEndpoint.cpp.o): In function `logf': /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' /home/steve/Desktop/SDR/Pluto/ready/SoapySDR/include/SoapySDR/Logger.hpp:47: undefined reference to `SoapySDR::vlogf(SoapySDRLogLevel, char const*, std::__va_list)' ../common/libSoapySDRRemoteCommon.a(SoapyStreamEndpoint.cpp.o): In function `acquireRecv': /home/steve/Desktop/SDR/Pluto/SoapyRemote/common/SoapyStreamEndpoint.cpp:227: undefined reference to `SoapySDR::log(SoapySDRLogLevel, std::string const&)' collect2: error: ld returned 1 exit status client/CMakeFiles/remoteSupport.dir/build.make:227: recipe for target 'client/libremoteSupport.so' failed make[2]: *** [client/libremoteSupport.so] Error 1 CMakeFiles/Makefile2:140: recipe for target 'client/CMakeFiles/remoteSupport.dir/all' failed make[1]: *** [client/CMakeFiles/remoteSupport.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2