SDRPlusPlus
SDRPlusPlus copied to clipboard
AlexandreRouma
arm64 nightly builds
Can you please work on a arm64 release ? alotof us on arm are playing with sdr
arm64 what? macOS? Windows? Linux? I only one a single raspberry pi and it does the armhf builds. Github's CI still doesn't support M1/M2 so I can't compile for that either.
Arm64 linux not armhf…. But true arm64 linux support
On Jul 30, 2023, at 18:29, AlexandreRouma @.***> wrote:
arm64 what? macOS? Windows? Linux? I only one a single raspberry pi and it does the armhf builds. Github's CI still doesn't support M1/M2 so I can't compile for that either.
— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1154#issuecomment-1657280941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEITP6ORNWMTZKQ4JAVYA3XS3N3BANCNFSM6AAAAAA25MIT7Q. You are receiving this because you authored the thread.
I tried to build the Linux arm64 version of sdr++ (by running the original bullseye arm64 rpi image in virtualization). I didn't check the functionality, I don't have Raspberry Pi hardware... Mr-Precise/SDRPlusPlus/nightly-arm64 I'm planning to buy a Raspberry Pi 4, and I'm also interested in whether it will work
Arm64 linux not armhf…. But true arm64 linux support
Read what I said again. I'm telling you the only existing arm build is armhf, I know you want arm64 which is different.
NO I have built on arm64 . I built from src and it builds and runs fine.
On Aug 21, 2023, at 19:32, AlexandreRouma @.***> wrote:
Arm64 linux not armhf…. But true arm64 linux support
Read what I said again. I'm telling you the only existing arm build is armhf, I know you want arm64 which is different.
— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1154#issuecomment-1687196978, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEITP6HJMM3HHCXXRGA7VTXWPVXZANCNFSM6AAAAAA25MIT7Q. You are receiving this because you authored the thread.
NO I have built on arm64 . I built from src and it builds and runs fine. … On Aug 21, 2023, at 19:32, AlexandreRouma @.***> wrote: Arm64 linux not armhf…. But true arm64 linux support Read what I said again. I'm telling you the only existing arm build is armhf, I know you want arm64 which is different. — Reply to this email directly, view it on GitHub <#1154 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEITP6HJMM3HHCXXRGA7VTXWPVXZANCNFSM6AAAAAA25MIT7Q. You are receiving this because you authored the thread.
The point he is making is Github's CI doesnt support building for M1/M2, and the build system he uses for ARM is a raspberry pi on 32bit. As such he can't make packages since he does not have access to a system that builds for 64bit ARM (ARM64).
it is already supported on aarch64, currently I'm using SDR++ on aarch64 linux and it works very well on raspberry pi 4
$ uname -a
Linux raspi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
Just install arm64 linux instead of armhf on raspberry pi 4, clone repository and build it. It works ok.
Is an anyone running SDR++ on a Mac / M1 or M2 ? I am trying to port this to iPadOS for the iPad Air and Pro models that use the Mx chips. Building the Volk library is where I need help at the moment. If someone has built this for a Mac running aarch64, would you please send me the Volk static libraries (e r I s I at c o m c a s t . n e t)
Is an anyone running SDR++ on a Mac / M1 or M2 ? I am trying to port this to iPadOS for the iPad Air and Pro models that use the Mx chips. Building the Volk library is where I need help at the moment. If someone has built this for a Mac running aarch64, would you please send me the Volk static libraries (e r I s I at c o m c a s t . n e t)
I use the sdr++ client for intel on M1, it works quite well, but there are some instabilities in the client and sound server
volk is in brew. brew search volk
its there
On Sun, Sep 24, 2023 at 9:44 AM Bogdan Shyrokostup @.***> wrote:
Is an anyone running SDR++ on a Mac / M1 or M2 ? I am trying to port this to iPadOS for the iPad Air and Pro models that use the Mx chips. Building the Volk library is where I need help at the moment. If someone has built this for a Mac running aarch64, would you please send me the Volk static libraries (e r I s I at c o m c a s t . n e t)
I use the sdr++ client for intel on M1, it works quite well, but there are some instabilities in the client and sound server
— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1154#issuecomment-1732573785, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEITPYBYDCTO75QNMHAMTDX4A2MZANCNFSM6AAAAAA25MIT7Q . You are receiving this because you authored the thread.Message ID: @.***>
Does installing the Volk package have any advantage when running SDR++ in client mode with a server on a remote Linux box, or is it just helpful for using the server mode? I’m actually a bit unclear on what Volk does.
On Sep 24, 2023, at 10:12 AM, Richard Neese @.***> wrote:
volk is in brew. brew search volk
its there
On Sun, Sep 24, 2023 at 9:44 AM Bogdan Shyrokostup @.***> wrote:
Is an anyone running SDR++ on a Mac / M1 or M2 ? I am trying to port this to iPadOS for the iPad Air and Pro models that use the Mx chips. Building the Volk library is where I need help at the moment. If someone has built this for a Mac running aarch64, would you please send me the Volk static libraries (e r I s I at c o m c a s t . n e t)
I use the sdr++ client for intel on M1, it works quite well, but there are some instabilities in the client and sound server
— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1154#issuecomment-1732573785, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACEITPYBYDCTO75QNMHAMTDX4A2MZANCNFSM6AAAAAA25MIT7Q . You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/1154#issuecomment-1732594143, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGI5CYRRZ4HZ2KKPL5DBIOLX4BEWDANCNFSM6AAAAAA25MIT7Q. You are receiving this because you are subscribed to this thread.
@H6LS1S , I want to run this on an iPad so I would prefer not to run in an x86 emulator.
@RichNeese , I have installed Volk via brew and just found the arm64 version in the download directory. My next step is to see if .dylib files can be used in iPadOS.
@johntdavis84 , Volk is two things; a specification of a set of DSP - type vector instructions and it is an implementation of the spec on different processors. This allows Volk users to focus on the mathematical functions and not on the hardware specific implementation of those functions.
*If the SDR++ server is streaming I/Q data, then Volk is important to the client function. This might not be true. I am beginning to look more closely into where Volk is used. The M17 decoder includes headers for it. Stay tuned...
Does installing the Volk package have any advantage when running SDR++ in client mode with a server on a remote Linux box, or is it just helpful for using the server mode? I’m actually a bit unclear on what Volk does. … On Sep 24, 2023, at 10:12 AM, Richard Neese @.> wrote: volk is in brew. brew search volk its there On Sun, Sep 24, 2023 at 9:44 AM Bogdan Shyrokostup @.> wrote: > Is an anyone running SDR++ on a Mac / M1 or M2 ? I am trying to port this > to iPadOS for the iPad Air and Pro models that use the Mx chips. Building > the Volk library is where I need help at the moment. If someone has built > this for a Mac running aarch64, would you please send me the Volk static > libraries (e r I s I at c o m c a s t . n e t) > > I use the sdr++ client for intel on M1, it works quite well, but there are > some instabilities in the client and sound server > > — > Reply to this email directly, view it on GitHub > <#1154 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/ACEITPYBYDCTO75QNMHAMTDX4A2MZANCNFSM6AAAAAA25MIT7Q > . > You are receiving this because you authored the thread.Message ID: > @.***> > — Reply to this email directly, view it on GitHub <#1154 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGI5CYRRZ4HZ2KKPL5DBIOLX4BEWDANCNFSM6AAAAAA25MIT7Q. You are receiving this because you are subscribed to this thread.
Volk is a cross-platform Vector optimization library, so when we are using FFT (Fast Fourier Transform) Volk would help a lot. Basically the project hand-tunes mathematical operations to properly and efficiently use SIMD instructions.
Although personally, I say use the GPU for this using OpenCL, but I'm not sure what specific goals you have for the program as a whole when processing wave forms.
I am trying to port this to iPadOS for the iPad Air and Pro
Short of writing an entire render backend for iOS, you won't get this running. In any case, apps don't have the raw access to USB ports that is needed for SDR hardware to work, and is why little to no SDR software is available on the platform. The few that you can run are remote clients only.
Does installing the Volk package have any advantage when running SDR++ in client mode with a server on a remote Linux box, or is it just helpful for using the server mode? I’m actually a bit unclear on what Volk does.
Volk does all the SIMD abstractions to make the basic operations in the DSP code such as addition, multiplication, dot product, etc much faster on every platform that supports vector instructions.
Volk is a cross-platform Vector optimization library, so when we are using FFT (Fast Fourier Transform) Volk would help a lot. Basically the project hand-tunes mathematical operations to properly and efficiently use SIMD instructions.
Not only is volk not used to compute the FFT but it doesn't even have that functionality to begin with.
Although personally, I say use the GPU for this using OpenCL, but I'm not sure what specific goals you have for the program as a whole when processing wave forms.
OpenCL has way too much overhead to do live signal processing or even render the FFT, which is one of the least CPU heavy tasks the software does anyway. Not to mention systems with only integrated GPUs...
I am trying to port this to iPadOS for the iPad Air and Pro
Short of writing an entire render backend for iOS, you won't get this running. In any case, apps don't have the raw access to USB ports that is needed for SDR hardware to work, and is why little to no SDR software is available on the platform. The few that you can run are remote clients only.
Actually for iPadOS this is possible, as you are able to use drivers that are written in DriverKit.
Although personally, I say use the GPU for this using OpenCL, but I'm not sure what specific goals you have for the program as a whole when processing wave forms.
OpenCL has way too much overhead to do live signal processing or even render the FFT, which is one of the least CPU heavy tasks the software does anyway. Not to mention systems with only integrated GPUs...
That makes sense actually, although integrated GPUs would do just fine in all honestly, any in the past 6 years easily hit 1TFLOP. Just to clarify though, I do agree the CPU is just fine, especially after you defined the scope.
Actually for iPadOS this is possible, as you are able to use drivers that are written in DriverKit.
No SDR device has this sort of drivers. Almost all SDR use libusb for their driver which is why they need raw USB access.
Actually for iPadOS this is possible, as you are able to use drivers that are written in DriverKit.
No SDR device has this sort of drivers. Almost all SDR use libusb for their driver which is why they need raw USB access.
Now im sure some work would need done to adjust this for use with DriverKit, but it has already been done for a LONG time... libusb for iOS.
Actually for iPadOS this is possible, as you are able to use drivers that are written in DriverKit.
No SDR device has this sort of drivers. Almost all SDR use libusb for their driver which is why they need raw USB access.
Now im sure some work would need done to adjust this for use with DriverKit, but it has already been done for a LONG time... libusb for iOS.
Look in the README under dependencies, there is an explanation.
Feel free to contact every device manufacturer about this if you want to spend months getting every driver working with it. Note that even on android , where libusb can be used natively, it took me several weeks to get only a subset of devices working properly. Have fun!
It is a huge challenge and I have doubts about whether I can port it to the iPad. My goal is to be able to use the USB port on my iPad with a USB C connector. As you said, even with OpenGLES (which is depreciated but still available) a backend has to be created and I have spent the last few weeks just trying to get things to compile and link properly. The iPad hardware is nice but porting to iOS is a challenge.GeneSent from my iPadOn Oct 9, 2023, at 5:44 PM, AlexandreRouma @.***> wrote: Feel free to contact every device manufacturer about this if you want to spend months getting every driver working with it. Note that even on android , where libusb can be used natively, it took me several weeks to get only a subset of devices working properly. Have fun!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
An update on my status fwiw: I am looking into using SDL and Metal as the renderer for imgui. I have compiled versions of volk, sdl2 and fftw for iPadOS. SDR++ uses a mix of imgui and OpenGL calls which is why I thought OpenGLES would be the way to go, but it is depricated in iOS. I have decided that I need to take a few steps backward if I hope to be able to move forward, so I will first work on a version that uses SDL and Metal on a MBP. Once that is working, porting to iOS should be much more straightforward for the core function. Getting the USB interface working fully is something that I have no way to check out. I do have an RTL dongle and that’s where I hope to start. Gene
I am trying to run SDR++ on a new PI5 running a 64 bit OS after bullseye, which is bookworm. Any help would be appreciated. I would really rather not build from source but I will if that is the only way to get there.
Look in my fork of the Master repo. https://github.com/jerrynsr/SDRPlusPlus/tree/patch-1 I built a deb package for Bookworm. To build all the plugins I need two missing files. pll/dsp.h and pll/demodulator.h I have been looking at older repos to merge into my checkout code to test compile but I have not found it. It's almost as if this version is a rewrite and not all the code is merged in.
