Windows Support Thread #29
Replies: 51 comments
-
|
I'm working in a Windows VM as well to try and get results. It might take a few days since Windows and Python don't play together as nice as you may think. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: I added an argument when calling nrsc5-dui.py that lets you specify the path to nrsc5(.exe). Needs a final slash, but I think I should make it add it if it's not there. Syntax is: |
Beta Was this translation helpful? Give feedback.
-
|
So it turns out right now due to the dependency on |
Beta Was this translation helpful? Give feedback.
-
|
I was able to the get GUI up and running under WSL1 Ubuntu 20.04, however I think there's a problem with nrsc5 on WSL. I initially tried getting this going using python 3.9 but eventually ran into an error importing 'gi'. It was probably some sort of version mismatch, so I installed everything using python 3.8 and then I'm able to pull up the GUI, but the audio decode doesn't do anything. So I tried nrsc5 standalone from the command line. I get: "shared memfd open() failed: Function not implemented" which seems like it just might not work under WSL1. It seems that WSL2 doesn't support USB devices, so... maybe use rtl_tcp?? I haven't tried WSL2 yet, but perhaps that's the next step. I was able to get nrsc5.exe to run under MSYS2... so if there's a way to get nrsc5-DUI running in MSYS2, that potentially might be another way. I started that path but it became difficult quickly. |
Beta Was this translation helpful? Give feedback.
-
|
A follow up... maybe the issue isn't the memfd error but rather getting pulseaudio working within WSL. There's a few webpages talking about how to set it up, and I have it halfway working using Pulseaudio v1.1. but it seems that largely I can't get it to find my audiocard currently. I can test it using pacat < /dev/urandom and I hear things, but when I type aplay -l I get no soundcard... if I run nrsc5, I get Open Device failed. So maybe the real monster here is pulseaudio on WSL. |
Beta Was this translation helpful? Give feedback.
-
|
'Open Device Failed' is usually the message nrsc5 generates when it can't open a usb channel to the radio. That may not necessarily mean the usb is bad, just that the radio is non-responsive, so can also mean the radio is jammed up. That happens when it gets confused. Reconnecting it usually fixes that. |
Beta Was this translation helpful? Give feedback.
-
|
Having said all that, if you can get nrsc5 running from a command window, and generate status messages without nrsc5-dui or even audio, then you're most of the way there. Once you get that, then get the audio operational, then nrsc5-dui. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, that was a helpful comment. I don't think WSL sees the USB rtl-sdr, however it can communicate via rtl_tcp. I was able to get nrsc5 working from the command line... pulseaudio server running windows-side. I got all of the normal status messages but the audio was slow and severely stuttered. Perhaps a result of pulseaudio being version 1.1. I can't seem to figure out how to use rtl_tcp from nrsc5_dui though... |
Beta Was this translation helpful? Give feedback.
-
|
rtl_tcp has to be running in the background and listening for a specific IP address, for example: In nrsc5-dui's settings, there should be the RTL_TCP IP. Enter the IP you set using the -a switch in that box, then click the Enabled button to the right of that. The next time nrsc5 is spawned by nrsc5-dui, it will command nrsc5 to use the radio found at that IP (using the default port of 1234). |
Beta Was this translation helpful? Give feedback.
-
|
Success, kind of. I edited the config.json file and input 127.0.0.1 as DevIP and UseIP=true. This successfully connects to rtl_tcp and DUI starts getting the stream. However, it's plagued by high BER of up to 27% and when it is able to decode audio it's extremely stuttered and slow. The signal is quite strong and shouldn't have trouble decoding, but my computer is fairly old. I will say this is possible, but it was a struggle to get it this far. I may try again with WSL2 to see if it has any improvement. |
Beta Was this translation helpful? Give feedback.
-
|
Heh... that's cheating, but those two things are basically the equivalent of what's in Settings. |
Beta Was this translation helpful? Give feedback.
-
|
Yea, I was blind to that button for some reason... |
Beta Was this translation helpful? Give feedback.
-
|
Success on WSL2 (Ubuntu)... Sort of. This needs some cleanup and a lot of documenting.. And I'm still having some difficulty keeping it stable, but I've now heard multiple alternate digital channels, and seen album artwork and weather/traffic maps. The GUI can tune the radio, and it works great until one of the many, many hacks and background cheats I'm using fails. I have the Windows version of rtl_tcp.exe running on the WSL2 network address of the windows host in one window. You have to set the (WSL2 network 172.*) IP address of the Windows host in the cfg/config.json file to make nrsc5-dui use it, but it seems to work just fine. I am running PulseAudio for Windows in another window and listening for a TCP stream on the same WSL2 interface. I have the WSL2 Ubuntu instance configured to forward audio to it over the network. I was unable to get nrsc5 to play audio across the network back to Windows without significant choppiness. I think this may have to do with sample rate, and a lack of resampling, but was unable to fix it. So, I created a fifo on /tmp/stream and have mplayer running in the background playing it through PulseAudio back to Windows. This takes care of the audio quality issues I had. Then I modified nrsc5-dui.py to add "-o /tmp/stream" to the nrsc5 command line when it calls the program. I also installed VcXsrv and did all of the network forwarding work to get a GUI from WSL2 up in it. So now, assuming I have VcXsrv, Pulse, and rtl_tcp.exe running on Windows, and I have an "mplayer -cache 2048 /tmp/stream" running in WSL2, I can just call "nrsc5-dui.py" from my WSL2 Ubuntu instance and the window opens up on the desktop, it uses the local RTL-SDR I have on this Windows machine, and everything works! I'm going to try to clean this process up a bit in the coming days, and will attempt to do a better job of documenting it, but I figured I should let everyone know that it is possible to get this working well enough to use, and let you know the ingredients, even if I haven't written up a recipe yet. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting solution... wondering if anyone's gone and rebuilt the nrsc5 and sox packages under mingw to make it all more native rather than go through some *nix hoops. Not sure where 105.7 is, but was testing a little on a Philly station (106.1 WISX) that also has a smooth jazz stream and at 9:37 ET played this: |
Beta Was this translation helpful? Give feedback.
-
|
West Michigan. Apparently there's not enough of a market to populate the sub-channels with bespoke content. Looks like this is simulcast on iHeart Media stations everywhere. I actually thought about trying mingw when I hit about the 6 hour mark on this. I was already pot-committed on WSL2, though. I hadn't actually used WSL2 before now, so it was a good learning exercise. I'm not sure what the USB device support looks like with mingw, but even if you still have to use rtl_tcp, eliminating all of the pulseaudio/X11/mplayer stuff would be great. Although, Microsoft is promising a native solution to the WSL2 GUI/Audio problem too. So, hopefully, it will just run without issue after a Windows update... Eventually. |
Beta Was this translation helpful? Give feedback.
-
|
You may have been right about your particular dongle having an issue with the current version of SDR#. I'm talking about a conflict between a Windows-built rtl_sdr library and likely anything that tries to communicate with an RTL_SDR V3 dongle, which also exists. I've had to reset my dongle and Windows several times in order to get things back to normal after attempting to run nrsc5 with anything other than via rtl_tcp. This appears to be completely separate from your issue, which you never said predated this project by more than a year. So I apologize if I tried to link the two thinking this was recently discovered when trying to run this project. That is what this thread is meant to discuss. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so I've updated the README. Would appreciate it if I can get a second set of eyes on it to make sure I've accurately captured the pertinent parts of others' experiences. |
Beta Was this translation helpful? Give feedback.
-
Then there may be the problem it very well could be SDR# is now being built with the same rtl_sdr library you used and that is the problem child? Oh, well it is just a thought. Good luck. |
Beta Was this translation helpful? Give feedback.
-
|
Again, my SDR# worked well until I ran nrsc5 in Windows, so no. |
Beta Was this translation helpful? Give feedback.
-
|
Well, didn't work on mine no matter what I used until I fell back to an earlier build. I guess it is a big fuck it on Windows for this, or a new version of SDR#. Not really worth all the hassle for this as one of the previous comments said. As I previously said thanks for trying but there is something here that you are missing, or overlooking when 1 doesn't work but did work on prior builds and your project doesn't work for shit on W10 (iow at all). Anything common between the two? Who knows. |
Beta Was this translation helpful? Give feedback.
-
|
Rethinking the Windows-specific issues:
Edit: I should specify that any changes I make would be Windows-only with zero impact to Linux/Mac. |
Beta Was this translation helpful? Give feedback.
-
|
Not Windows-specific but I found the reason nrsc5 wasn't working for me: the direct sampling option. Even with direct-sampling turned off (the default), the call to specifically turn it off in the main function would cause my receiver to stop working altogether. This is all it took to make it work for me: //if (nrsc5_set_direct_sampling(radio, st->direct_sampling) != 0)
//{
// log_fatal("Set direct sampling failed.");
// return 1;
//}Doing that under Linux fixed nrsc5 for me. It didn't work on Windows still (but this time there was zero output so who knows what it's doing?), but it's possible I did something wrong in my rebuild.] Edit: I realize this isn't specific to nrsc5-dui, but figured I'd put it here in case it helps someone else trying to get this working. |
Beta Was this translation helpful? Give feedback.
-
|
Had some time so rebuilt nrsc5 and rtl_sdr under MSYS2 32 bit. No joy. Same issue. Edit: Again, it's possible although not really probable that this could be due a conflict in the way my Win10 VM does USB. |
Beta Was this translation helpful? Give feedback.
-
|
Based on some recent code changes to nrsc5 (albeit for NEON code, and unrelated to this), I decided to cross-compile the whole mess again for Windows under mingw-w64. After dragging all the rebuilt pieces over to Win11, it seemed to work! Still some stability issues (cb errors and finally some rtlsdr read errors), but I actually got audio out of it and it was reading keypresses now. That's more than I got the last time so maybe this isn't a complete lost cause after all. |
Beta Was this translation helpful? Give feedback.
-
|
Quick update on this: Still some stability issues, however I think these are related to USB stability issues within the Windows VM I am using (Parallels). These are annoying, vis-a-vis nrsc5, but not show-stoppers. |
Beta Was this translation helpful? Give feedback.
-
|
I'm having trouble getting this to run under Windows 10 with the latest msys2. Not sure what I'm doing wrong but whenever I try to run nrsc5-dui.py I get the error: ModuleNotFoundError: No module named 'termios'. I've installed all the dependencies listed and double checked the instructions were followed correctly. Googling for solutions to missing termios hasn't been fruitful. I couldn't figure out how to install python 3.9 under MSYS2 so this is the version I have installed: mingw64/mingw-w64-x86_64-python 3.10.8-2. Is this the issue? |
Beta Was this translation helpful? Give feedback.
-
|
Read the readme. There are several issues with trying to get this to work properly in Msys2. What you've run into is the fact that Windows isn't Posix compliant. IOW: There is no termios available for Windows, but it's required to spawn nrsc5 in a shell. I'm looking to replace it for Windows but it's not a simple fix. |
Beta Was this translation helpful? Give feedback.
-
|
I saw the readme but figured I could find a way. Cygwin supports termios but I had trouble with out of date glib, otherwise I think it would work there. I did eventually get it working using Windows Subsystem for Linux 2 and Ubuntu 22.04 LTS (20.04 had issues). I just compiled everything like I was under linux except I used the cross-compile option for nrsc5 and Im listening successfully. I also had to update the max length for the rtl_tcp ip address as it was too short for port numbers. |
Beta Was this translation helpful? Give feedback.
-
|
d'oh... forgot the port numbers. |
Beta Was this translation helpful? Give feedback.
-
|
Ok.. Just upped it from 16 to 21, which should be enough. |
Beta Was this translation helpful? Give feedback.
-
Creating this as a thread for RTL-SDR Users on Microsoft Windows Operating Systems. Since neither myself or Mark use Windows, we will be relying on other users to test and give issues. Based on what I know, you just need to install python 3.8 or 3.9 and install the required modules from Pip, then install nrsc5 for Windows and try and run the application. You might have to change the
/usr/local/bin/nrsc5hard-coded path to the nrsc5.exe file installed on Windows or the one in the nrsc5-dui folder. We could really use some Windows testers, so if you are using that OS and are skilled enough with how python works then feel free to help out!Beta Was this translation helpful? Give feedback.
All reactions