Add Windows for ARM64 builds and implement RAW_IO in libs

[JVital2013]

Feature description

Hello there! I would like to request Windows ARM64 builds for SDR++. I'm going to put a lot of notes into this enhancement request because I've done a lot of research on this topic for SatDump implementation with great results, and want to help you and other technical readers if I can.

Personally, I believe we're going to be seeing more and more Windows on ARM devices. I bought one (well, two - long story) Snapdragon X laptops. I find them extremely good machines for SDR use due to their long battery life, good CPU performance, and low RF noise output. However, support in the SDR community is mostly lacking, other than what I've done in SatDump. In Windows 11 24H2, the x64 emulation is quite good - but it's still not as good as native. I did some benchmarking and posted the results at https://x.com/JVital2013/status/1830121682511487278.

Of course, there are a number of issues that need to be addressed to optimize these builds.

Volk patches

In its current state, volk does not use any NEON optimization on Windows. I have a PR open with them at gnuradio/volk#769 that fixes the NEON/NEONv8 kernels for use on Windows (if the volk guys see this: sorry, I'll get back to you soon I hope!)

Also, volk will need to be built with the master branch of cpu_features to fix NEON detection. This one has been merged, but it's not in a "released" version of cpu_features yet - google/cpu_features#363

RAW_IO in libusb and RTL-SDR/AirSpy/HackRF/etc
This is perhaps the most important part, and can be done without tackling the arm64 build itself at all. In libusb's current state (x64 emulated or native), both Snapdragon X laptops I tested dropped samples from all USB SDRs like crazy - it mostly works for basic radio listening, but that's about it. After a bunch of tinkering, I found the solution is to implement RAW_IO in LibUSB and the SDR libs themselves. You can read about RAW_IO here: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-functions-for-pipe-policy-modification.

Support for this is non-existent in SDR libs and exists only as a PR in libusb itself. I'm hoping to push for this to change because it is necessary to prevent sample drops with the current state of Windows on ARM64, and it seems to help on many x64 machines as well. A quick rundown of these changes follows:

• LibUSB's PR, originally written by one of the HackRF devs: Reintroduce RAW_IO support in WinUSB backend libusb/libusb#1512
• Patch for HackRF: Implement RAW_IO with WinUSB greatscottgadgets/hackrf#1483
• Patch for AirSpy: https://github.com/JVital2013/airspyone_host/tree/rawio
• Patch for AirSpy HF: https://github.com/JVital2013/airspyhf/tree/rawio
• Patch for RTL-SDR: https://github.com/JVital2013/librtlsdr/tree/rawio

(I'm sure you get the idea)

Other notes
Most of my focus in this has been in SatDump, but I have built SDR++ in the same way/with the same libs. Admittedly the one part I did not tackle is codec2/m17 because I haven't wanted to deal with msys2, so that will need to be addressed (among other things, most certainly).

A few SDRs rely on the FX3 SDK, which does not have an arm64 build as of this writing. UHD also fails to build due to some strange endianness bug in an included library. I haven't put any additional work into either of these.

Users may need to be made aware that Zadig is not currently working on Windows for ARM64 due to driver enforcement issues. It is difficult to boot these machines with driver enforcement disabled, so it is simpler to just assign WinUSB to the device in device manager when necessary.

OK, I'm done now
Sorry, I know I put more here than I really needed to - and I know you could have figured out all of this on your own, but I hope this speeds along the implementation of Windows for ARM64 builds - if you so choose to go this route!

[AlexandreRouma]

Thanks for the notes, but unfortunately, I don't have any Windows on ARM hardware and I don't plan to waste money by buying some either. I therefore do not plan to ever support Windows on ARM because I can't support something I can't test.

I am also EXTREMELY opposed to any of that RAW_IO bullshit being implemented in the SDR drivers themselves. All these drivers are OS agnostic, any of these modifications should be done to libusb and NOT the SDR drivers.

I might re-open this if Windows on ARM quits being the joke that it currently is, but seeing the direction Microsoft is taking and knowing how locked down anything Qualcomm makes is, I don't have high hopes...

[martinling]

I am also EXTREMELY opposed to any of that RAW_IO bullshit being implemented in the SDR drivers themselves. All these drivers are OS agnostic, any of these modifications should be done to libusb and NOT the SDR drivers.

For what it's worth: this isn't possible for specific technical reasons. If it could have been done that way, it would have been done.

The basic issue is that RAW_IO places some constraints on what transfer sizes the program can use. It's only safe for libusb to enable RAW_IO for an endpoint if it can be certain that all future transfers the application makes will satisfy the size requirements. This means it can't be done transparently; the application has to opt in.

The API that's been selected reduces opting-in to a couple of lines of code which have no effect on systems where this doesn't matter. That's really the best we can reduce it to.

[AlexandreRouma]

Then something has to be fixed on the Windows side. We can't require to add lines of code specifically for one goofy operating system that almost nobody uses to every single SDR driver in existance (almost all of them use libusb). Bulk and Iso transfers have been working fine with libusb on all operating systems (including on ARM with linux and MacOS) for decades.

[martinling]

Then something has to be fixed on the Windows side.

This is not realistically going to be fixed on the Windows side, it's baked into the WinUSB API. And WinUSB is the only option for how to access these devices that can be made to work out of the box for users.

We can't require to add lines of code specifically for one goofy operating system that almost nobody uses to every single SDR driver in existance (almost all of them use libusb)

That's exactly what we're doing in HackRF, and I expect that the other projects will follow.

Bulk and Iso transfers have been working fine with libusb on all operating systems (including on ARM with linux and MacOS) for decades.

Unfortunately it's not the case that everything has worked fine for decades. I've been running into this problem since at least when I started working on the sigrok project in around 2013 (where it affects the FX2-based logic analyzers in particular).

Without RAW_IO being enabled, there have always been problems with samples getting dropped when using bulk/interrupt transfers via WinUSB on capture devices with small hardware buffers. Meanwhile the exact same arrangements will work fine on Linux and MacOS on the same hardware.

Devices that use isochronous transfers aren't affected by this issue and don't require the RAW_IO changes. It's specific to inbound bulk and interrupt transfers only.

In many cases it can look like things work fine, but only as long as the sample rate is low enough, or only when there's nothing else going on which might increase the transfer resubmission latency on the host side. In many scenarios users won't even notice that data is being lost, because many devices will just drop samples to recover without any warning.

[AlexandreRouma]

This is not realistically going to be fixed on the Windows side.

Clearly it works on x86 windows, any systemic issue on Windows on ARM is a windows bug and has to be fixed at that level. Windows on ARM has always been, continues to be and probably always will be a joke. Wasting time and effort just to get around Microsoft's incompetence is silly at best and bad for the code quality of the projects involved at worse.

That's exactly what we're doing in HackRF, and I expect that the other projects will follow.

You do you. I'll highly discourage this change to the projects I work for/with.

capture devices with small hardware buffers

So basically no modern SDR.

In many cases it can look like things work fine, but only as long as the sample rate is low enough, or only when there's nothing else going on which might increase the transfer resubmission latency on the host side. In many scenarios users won't even notice that data is being lost, because many devices will just drop samples to recover without any warning.

I'm speaking from experience implementing and testing support for devices that have a sample rates > 60MS/s. I've never had any repeatable sample loss (which are detectable either when the device specifically implements detection or when demodulating digital signals) on all 4 x86 windows machines I have.

In any case, this has gone very far from the post title so I'll go ahead and lock this thread.