petrinm / soapyshared Goto Github PK

I'm trying to install SoapyShared on my RPi 4, Raspbian 11. I believe the file "test_resampling.cpp" is missing in the "units" directory. When I run cmake, I get the following error:

CMake Error at units/CMakeLists.txt:25 (add_executable):
     Cannot find source file:

    test_resampling.cpp

     Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
     .hpp .hxx .in .txx


    CMake Error at units/CMakeLists.txt:25 (add_executable):
     No SOURCES given to target: test_resampling


    CMake Generate step failed.  Build files cannot be regenerated correctly.

I have installed the dependencies and as far as I can tell have followed the instructions. I would appreciate any help.

I am using Debian Buster with the soapy packages and -dev installed from Debian repository. It is version 0.6
When compiling SoapyShared I get an error:
fatal error: SoapySDR/ConverterRegistry.hpp: No such file or directory
other files are available in /usr/include/SoapySDR

Does this package require version 0.7 of SoapySDR or is it likely that I need to install another package that brings that file?

Using sleep to check for new data in the shared buffer can cause problems for applications requiring low latency, especially if the delay is not configurable. As suggested in tejeez/shmbuffer#1 , a process-shared condition variable could be used instead. I think it could work like this:

After seeder has copied a buffer of samples from slave to shared memory, it calls pthread_cond_broadcast. When leecher finds there is not enough new data in the shared buffer, it calls pthread_cond_wait and then checks again. To implement timeout, it could call pthread_cond_timedwait instead.

A broadcast condition variable is ignored by processes not waiting for it, so it should work nicely without extra overhead even if an application processes data in larger blocks and misses some notifications in between.

The frequency of notifications would be determined by the buffer size used in the seeder. This means the minimum latency could be controlled by configuring this buffer size, which makes sense since it determines the minimum possible latency anyway.

If POSIX shared memory is replaced by boost for better cross-platform support, a similar mechanism seems to be boost::interprocess::interprocess_condition functions notify_all and timed_wait.

The seeder does not pass calls to GPIO (or I2C, SPI, clock configuration, etc) functions to the device driver. All the currently missing functions in device class should call the corresponding functions in the slave device.

• Consider using a FIR or CIC filter instead of the IIR because linear phase response would be preferable
• Add support for non-integer resampling ratios (possibly using msresamp_crcf in liquid)
• Check whether readStream should always try to return exactly the requested number of samples (unless timeout happens). Now it can return less if the shared buffer wraps around or if the resampler returns less.
• Add support for multiple channels (MIMO)
• Add support for other data types

For hardware which supports them, the buffer timestamps in readStream and writeStream are useful for a number of purposes:

• Synchronization of RX and TX signals
• Controlling the latency of TX signals
• Absolute timing of RX signals on hardware with a PPS input
• Detecting lost RX samples

How should we pass the timestamps between seeder and leecher? For RX, the shared buffer could contain the calculated timestamp of the latest sample. readStream would then use it to calculate the timestamp for the first sample in the returned buffer. Note that this might need locking in the state structure or an atomic way to update both the sample pointer and the latest timestamp at the same time.

For TX, what if we don't use a similar ring buffer but somehow pass the writeStream calls more directly together with a timestamp? It would still allow multiple leechers to transmit at different times. Simultaneous transmission from multiple leechers (with summation of signals) wouldn't work but doesn't work now either. Note that resampling might add some challenges for handling the timestamps.

How about hardware time functions? For example, on USRP, getHardwareTime("PPS") returns the timestamp of the sample during which the latest PPS pulse happened, so the value updates once a second. Should these calls also be passed to the seeder and return value back to the leecher?

The discovery process of SHM buffers in the leecher driver is not very robust. It works in the Ubuntu but that's it. The problem is how non-standard the OS-level SHM implementations are, even inside POSIX compatible systems...

On Linux based systems the named SHMs can be discovered by listing files in /{dev,run}/shm/. This is a convention in POSIX based systems but it's not foolproof method and doesn't work always. For example, FreeBSD doesn't have such directory.
Also based on literature, MacOS might implement similar accessibility to via /dev/shm but once again not sure is it always available. On Windows, listing the named SHMs seems purely impossible. It's somehow possible by traversing through the whole process tree and parsing process memory section information.

So... a discovery procedure based on assumption that a list of SHM is available by the system might not be the best method.
An alternative method could be to store a list of SoapyShared-buffer names in a "meta/index" SHM. This list would be updated in seeder driver every time a new SHM is created or destroyed. This way the discovery procedure could just read the meta-SHM and test the each name in the list. The advantage of this approach would be that it the dependencies to underlying system/OS implementation are minimal.

More investigation and ideas required.