RTL_TCP and WSL2 with nrsc5-dui

[ferrellsl]

This is probably not the best place to address the problem I'm having with nrsc5, nrsc5-dui, and RTL_TCP, but I figured there might be some other users of nrsc5-dui that have experienced the same issue that I have and possibly have a fix for it. Nrsc5-dui runs great under WSL2. To have nrsc5-dui/nrsc5 access my SDR dongle which is hosted by Windows since WSL2 doesn't have direct USB access, I'm using RTL_TCP. Everything works great for 3-4 hours then I get audio skipping/choppy audio. When I check the Windows console where RTL_TCP was launched, I see the following immediately after the audio skipping begins. You can see where the initial gain was set correctly after tuning to a station, but after that 3-4 hour period of perfect playback, I get the audio skipping and the following output in the console window:

set gain 439
set gain 445
set gain 480
set gain 496
set gain 421
ll+, now 1
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll+, now 8
ll+, now 9
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
ll+, now 1
ll+, now 2
ll-, now 0
ll+, now 1
ll+, now 2
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll-, now 0
ll+, now 1

Has anyone else experienced this and found a fix? I'll try a different dongle in the mean time and see if that affects anything. Any assistance would be appreciated.

EDIT: Forgot to mention that I can hit the stop button under nrsc5-dui after playback gets choppy and then hit play once again and things go back to normal for another 3-4 hours but it gets annoying to have to do this continually.

EDIT: I also forgot to mention that nrsc5-dui, nrsc5, and RTL_TCP are all running on the same machine.

[ferrellsl]

It appears that II+, II- messages are related to TCP packages not being handled quickly enough or not enough buffering. I decided to try tripling the number of buffers (default is 15) as well as the number of linked list buffers to keep (default is 500). This is based on the info found here:

https://planetsofa.de/2015/04/bugs-when-using-rtl_tcp-memory-usage-of-rtl_tcp/

I'll report back on the result.

[ferrellsl]

OK, the above buffer fnckery didn't work and it appears that RTL_TCP is the culprit so I decided to remove RTL_TCP completely from the equation by providing WSL2 with USB access via USBIPD. So far it's working great. Here are the instructions that I used:

Install USBIPD-WIN. Get it here: https://github.com/dorssel/usbipd-win/releases
Next, open a Windows command prompt as an admin and run the command below:

usbipd list

You should see output similar to this:

BUSID DEVICE STATE
1-7 SDR Dongle Not shared
4-4 STMicroelectronics STLink dongle, STMic... Not shared
5-2 Surface Ethernet Adapter Not shared

Next, bind the device.

usbipd bind --busid 1-7

Verify that the device is now shared:

usbipd list

BUSID DEVICE STATE
1-7 SDR Dongle Shared
4-4 STMicroelectronics STLink dongle, STMic... Not shared
5-2 Surface Ethernet Adapter Not shared

Note that sharing a device is persistent; it survives reboots. You will only have to do it once per device.

Close the administrator command prompt; further commands do not require special privileges.

Now, attach the device to WSL2. Open a bash window to ensure that WSL2 is running.

Make sure you have opened a WSL2 bash command prompt first, then go to your Windows command prompt and attach the device to WSL2

usbipd attach --wsl --busid 1-7

You can confirm that the SDR dongle is now attached under Linux by typing the following in your bash shell:

lsusb

Your should see something similar to this:

Bus 002 Device 002: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 0bda:2838 SDR Dongle
Bus 001 Device 002: ID 1d6b:0002 Linux Foundation 2.0 root hub

Now, in your WSL2 bash window, start nrsc5-dui. Configure it for native USB support. Everything should work now without having to rely on RTL_TCP.

Below is an example Windows CMD file that will start nrsc5-dui just by double-clicking it.

Edit the below to match your configuration. It is assumed that you've already successfully built and installed nrsc5 and nrsc5-dui and that nrsc5-dui resides in your Ubuntu home directory.

---

REM shut down any other instances of WSL
wsl --shutdown
start wsl
REM Give WSL2 enough time (5 seconds) to load before we can attach the USB device
timeout 5 > NUL
REM Attach the device to WSL2
usbipd attach --wsl --busid 1-7
start bash -c "python3 ~/nrsc5-dui/nrsc5-dui.py"

---

You can minimize any CMD windows that open and the bash window too. It may be possible to start them minimized by editing the CMD file above but I haven't researched it further.

[ferrellsl]

Looks like I was a bit hasty and harsh with RTL_TCP because the problem still persists even after switching to USBIPD. Audio becomes choppy after about the same amount of time as when I use RTL_TCP. USBIPD like RTL_TCP is also IP based so something apparently either floods the network stack or prevents it from receiving data smoothly under WSL2 after a few hours. For now I'll stick to WSL2 and USBIPD and I'll just hit the stop/playback button every few hours to stop the jitter. I still prefer WSL2 over VMware or VirtualBox as the latter are such resource hogs and have lower performance than WSL2 on most of my systems. It's a problem that I'll just have to live with if I want to keep using WSL2 and nrsc5-dui together.

[markjfine]

It wouldn't surprise me if a lot of this is WSL2 not being able to fully handle the real time needs of continuous USB and audio processing like a host operating system might.

Are you using it so you can run *nix-type things while mainly working in Windows? If not, and could feasibly run Ubuntu natively, I was going to suggest possibly siphoning off some unused disk space and making your Win machine dual-booting. This is how my Legion is configured (but with Fedora). I mainly use Windows for gaming and Linux for radio.

[ferrellsl]

Yes, WSL2 is a virtual machine just like VMware or VirtualBox (without the admin GUI interface) and nrsc5-dui is completely under the control of the Ubuntu Linux kernel. Here's my neofetch report from WSL2:

nrsc5-dui runs without these choppy audio issues under VMware and VirtualBox on my low-end test system but that system only has 16GB of RAM and gets a bit sluggish with all the other apps I have running on Windows and the Windows Subsystem for Android running too., so I prefer WSL2 to avoid the sluggishness. So right now it looks like Microsoft needs to makes some changes to WSL2 as I've ruled out just about every other source of the problem.

Dual-boot would be nice but I'd lose some concurrent functionality as I have some Android apps running under the Windows Subsystem for Android (Daff Moon and MyRadar) and some native Windows apps all running at the same time.....real-time weather station with radar, moon phase, moon and sunset rise and set apps, and of course nrc5-dui running under the Windows Subsystem for Linux. I could run all of the non-native apps under VMware but things slow to a crawl with 2 or more VMware virtual machines running with only 16GB of total system RAM. I even tried running just nrsc5-dui and no other apps or other sub-systems to rule out if Windows was having a problem keeping up with so many concurrent apps and subsystems, but the problem remains. Right now it looks like there's just a problem with WLS2 itself that Microsoft needs to address.

I've even ran the same tests on a much more powerful i9-11980HK system with 64GB of RAM, with and without a lot of apps/subsystems running and the result is the same, choppy audio after 3-4 hours. On my more powerful rig, I'll just use VMware instead of WSL2 to run nrsc5-dui without any sluggishness or choppy audio. So at this point I'm 99% certain that Microsoft's implementation of WSL2 is the issue. At the 3-4 hour mark, something is flooding the network stack or blocking smooth data transfer to and from that stack. I thought it may be a power management issue for USB or network devices so I disabled Windows' ability to manage/shut off those devices but that didn't help either.

This problem isn't going to keep me awake at night. I'll continue using WSL2 and just bite the bullet on that lower-end system and press the stop/play button when things get choppy. Gives me an excuse to my lazy butt up from my chair anyway! LOL! And on my higher-end system I'll just use VMware to run nrsc5-dui.

[markjfine]

Maybe there's a way to configure WSL2 to prioritize USB over other events.
You would think that on a fairly new i9 that divvying up processing power wouldn't be an issue.

[ferrellsl]

Yeah, I'm lead to believe it's actually some sort of bus arbitration or scheduling issue between WSL2 and Windows because nrsc5-dui will run flawlessly for that 3-4 hour period before things go haywire. My systems certainly have the horsepower to run nrsc5-dui. I've even installed Linux on an old Intel Celeron N4020 system with just 4GB of RAM and even that modest system had no issues whatsoever running nrsc5-dui for days straight.

This has actually been a fun and interesting side trip for me. Getting USB access for WSL2 has been on my to-do list for a while and now I've even found a nice GUI tool to make attaching devices to WSL2 even easier. It's called WSL USB Manager.

You can get the MSI installer for it here: https://gitlab.com/alelec/wsl-usb-gui/-/releases