nrsc5-dui
nrsc5-dui copied to clipboard
markjfine
Support for NRSC5 executables built for SDRplay functionality?
Hi, I use an SDRplay RSPdx device instead of the RTL ones and was able to build and use a forked version of nrsc5 that supports it no problem. A few of the command-line arguments are a little different than the RTL ones though and I wondered if you might be able to add a few tweaks so that nrsc5-dui can spit out the right flags for device id and allow you to tweak the gain settings? I don't know if you are still actively working on the project, but just figured i'd ask! nrsc5-dui is an awesome program!
Hi back, and thanks for the kind words. Yes, I'm still somewhat engaged in this, I've just not had much time to do it recently. Am thinking of making a few more enhancements given the time.
I think expanding to other devices is an excellent idea. I myself would personally prefer to use an AirSpy Discovery HF+ over the RTL because it's a lot more sensitive, selective, and less prone to artifacts in the sidebands. Perhaps we can swap ideas on how you modified nrsc5 for the SDRplay RSPdx so I can possibly emulate similar modifications for the AirSpy. In short, I have no problem expanding the calling interface to work with these or other specific radios. I'll also assume the command line is really all that needs slight modification and that nrsc5 still spits out the same info as before - this would make things very simple. Otherwise it might complicate things a bit.
Well it wasn't actually me that did the fork but here is a link to the project that did: https://github.com/fventuri/nrsc5
As far as I know, the output is all still the same and the only differences are in the flags for controlling gain and specifying the ID of the SDRplay device. I do have some coding/development experience in C and I know a little bit of python so i'd be happy to help and contribute in any way I can. I could post some logs/samples of output so you can compare/confirm it's the same output as nrsc5-dui expects already as well as more specific information on the syntax of these custom CLI flags.
I'm also interested in helping nail down a specific more official path for Windows 11 users to get it working under WSL2 as the current versions have all kinds of new support for native GUI apps with audio support and even graphics acceleration etc so theres gotta be an official way to run nrsc5-dui under that enviroment! Just let me know what you need and i'll try my best to pitch in! :)
It runs just fine under WSL. See: Simple Fix for Windows users/WSL2 · Issue #20 · markjfine/nrsc5-dui
| | | | | |
|
| | | | Simple Fix for Windows users/WSL2 · Issue #20 · markjfine/nrsc5-dui
I found a very simple fix to get your app running under Windows/WSL2 without any issues. No need for pulseaudio ... |
|
|
-- The quality of your thoughts will determine the quality of your life.
On Wednesday, October 26, 2022 at 12:16:33 PM MST, DragonBytes ***@***.***> wrote:
Well it wasn't actually me that did the fork but here is a link to the project that did: https://github.com/fventuri/nrsc5
As far as I know, the output is all still the same and the only differences are in the flags for controlling gain and specifying the ID of the SDRplay device. I do have some coding/development experience in C and I know a little bit of python so i'd be happy to help and contribute in any way I can. I could post some logs/samples of output so you can compare/confirm it's the same output as nrsc5-dui expects already as well as more specific information on the syntax of these custom CLI flags.
I'm also interested in helping nail down a specific more official path for Windows 11 users to get it working under WSL2 as the current versions have all kinds of new support for native GUI apps with audio support and even graphics acceleration etc so theres gotta be an official way to run nrsc5-dui under that enviroment! Just let me know what you need and i'll try my best to pitch in! :)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Not really to get into a Windows debate (since this is mostly about other radios), but I'd rather like to get it working so an additional environment such as WSL2 isn't even needed and still is able to spawn and interface with nrsc5.exe in a thread. The solution will be very involved and I just need the time to do it. I actually have a stand-alone Win11 box coming tomorrow, so trying to debug inside a VM (that had known USB problems on top of other things) will no longer be an issue.
Sorry I haven't gotten back to you sooner, but this is the usage info for the sdrplay build of nrsc5:
Usage: nrsc5 [-v] [-q] [--am] [-l log-level] [-d device-serial-number] [-p ppm-error] [-g gainRF.gainIF] [-w iq-output] [-o wav-output] [-A antenna] [--dump-hdc hdc-output] [--dump-aas-files directory] frequency program
I have also attached a log of the output when nrsc5 has tuned a station that also includes album artwork and traffic maps etc. I think its all the same as the standard version. Would it be alot of work to support the nrsc5 binary built for sdrplay? If there's anything else I can do to help in the development process, please let me know :)
Seems like I just need to make it automatically use --am when in the AM band (if it doesn't already) and add two entries for device and antenna (if the default isn't needed). I think everything else is similar and taken care of already. I just need to take a closer look at the log to see if it's posting the kind of responses needed.
So I did some tinkering with the python source code and have successfully gotten it working. The pipe communication seems to work exactly the same as the standard RTL build and all your regex parameters grab the data perfectly as far as I can tell. I even started tinkering with the .glade files to modify some of the fields for use with SDRplay devices (for example, on SDRplay devices, the IDs contain alpha-numeric characters so I had to change that from the numbers-only mode). For some reason, my version of GtkBuilder found version incompatibilties with some of your existing parameters like xalign etc. Do you plan to offer a completely separate build for SDRplay devices or would you add further fields, etc in the settings tab to select your device type for an all-in-one program?
I'll probably add a switch that shows/hides those two SDRPlay items and re-distro the existing thing. I may also look at the nrsc5 code to expand it and this app because there's a station here in DC that has 5 channels on it. I believe the current limit for nrsc5 is 4.
Currently have my head stuck in fixing some pretty complex threading-related audio pipe bugs in DReaM (Digital Radio Mondiale decoding for shortwave), but will attack this when that winds down.
Another thing with the SDRplays is that some models (like mine) actually have multiple antenna ports that you can select. Would you also be able to add a field for antenna port? The syntax in nrsc5 is quoted strings of "Antenna A", "Antenna B", etc.
Also, I didn't know you do dev work on DREAM! I freaking love that decoder. I have to have a strong signal usually though to maintain the audio lock. I tried getting the newer versions to work but they require all kinds of QT dependencies that made my brain hurt :)
That Antenna would have been one of the extra inputs, but if it's only two I can just add a switch for A or B rather than have a text field, which would be clumsy.
Yeah, I'd been involved on and off with Dream for almost 20 years now. The current version has some real issue with the way they open and close pipes across threads, which Qt doesn't like, so it has a habit of crashing when you change an input source or try to load a recorded file. I have a version that works on PCs without QtMultimedia (QtM is no longer distributed with Qt5 and Dream doesn't work on Qt6... yet). I have a list of the minimal dependencies and can provide some Intel-based builds if needed.
My RSPdx has 3 inputs. A, B, and C. Other models only A and B and yet others just only 1 connection and no setting necessery. I noticed in your code, you have stuff pertaining to Windows builds and I wondered what your plan was for that as I dual boot myself between linux and Windows 11. I was able to get it work via WSL2g with ALOT of difficulty. Had to install a ton of dependencies. The windows version of python3 has no equivalent for PyGObject but it would be great to have a version that I can run native-ish when im using Windows :)
Ok, combobox antenna select it is!
I've grown tired of VMs like WSL2 and Msys. Nothing works the way it should. I used to run Win11 and Fedora 36 in VMs on a Mac, but just bought a new Intel-based Lenovo and migrated both to it. The reason is because I had to upgrade my old Mac because nothing was supported on it anymore. New Mac is an M1 ARM architecture and the old Intel-based VMs wouldn't run on it. Quite a few things no longer run on it, such as my 360 controller and VB-Audio Cable. So, the last few weeks have been an adventure.
Almost forgot.. As for running on Win11, I am looking for alternate ways to get around those issues, now that I have a separate box that can actually use USB ports the way they're supposed to.
Yeah USB passthrough with VMs is iffy at best. Been there :) I think at some point soon, im just going to have dedicated machines for OSes. Too much of a pain forcing them to play nice with each other. M1 Macs are nice for portable devices, but a desktop computer, yeah I agree. Nothing works with M1 macs and Rosetta (or whatever they call their compatibility layer these days) is less than ideal. WSL2 is nice to have for terminal stuff, but GUI stuff and dedicated hardware support is wonky.
Have you ever considered porting nrsc5-dui over to something like C++ that could be built more easily for multiple platforms? Would be neat to wrap the actual nrsc5 C code around an actual GUI, no STDOUT pipes necessary :) Buuut probably not worth all the work. I'm very new to GUI coding but I want to learn more :) WxWidgets looks interesting.
Oh one other observation. I didn't realize at first that those sub-channel tabs are actually buttons, and if you select sub-channel 2 on one station, and then tune to another station that doesnt have a sub-channel, it wont work because it sends the value from previous tuning attempt. Maybe reset that to 1 after tuning is stopped? Also maybe you could have pre-populated labels for each one like "Ch 1", "Ch 2" so that its obvious what those are for when you first open the GUI. Just an idea :)
Funny you mention this button issue. At one time they had labels on them with the station name from the bookmarks on them. They should also show on the info tab with the type, as well as any digital feeds. See the screenshot at the bottom of the Code page. Something must have changed somewhere because as I was moving things to the Mac and PC I noticed it no longer looked like that.
I agree regarding developing a compiled app. Python was fun, quick, and made it easy to leverage from an original idea (nrsc5-gui), but it's starting to remind me of Java in the way things get deprecated so easily. I once wrote an entire ADRG map package with overlays and a map server that was prototyped in Borland Delphi and ported to Java before ESRI was even providing GIS options. Feel like that's how you keep maintainers employed because you're always having to chase that stuff. Qt is reminding me of this as well.
So, yeah, I may just port the whole thing into something that works once and keeps working. I hate having to say "It used to work". I now have Visual Studio on the PC, Xcode on the Mac, and virtually anything I need for Linux.
Yeah even the Form builder was complaining about deprecated parameters. "These parameters require at least version 3.16". So I change version to 3.16 and then it says "Ok, but now these OTHER object types were deprecated in version 3.12 and no longer valid". Damned if you do, damned if you don't LOL. wxWidgets is a very cross-platform-friendly toolkit for GUIs and I think it's alot easier to use to Qt.
Ok. Try pulling down a new nrsc5-dui.py and res/mainForm.glade. Basically the only two files I changed.
When you run it, click on Settings, click the Enable next to the SDRPlay # and enter the Serial#, then add just the antenna letter below it (I think it was B in the log you sent). You need just the letter B, not the whole "Antenna B" string.
This is a preliminary just to get things working. In the future I'll change the Antenna entry to a combobox. There are other interface changes I'll need to make in order to make it more error-proof.
dragonbytes, I noticed The new nrsc5-dui changes for SDRplay so I decided to try the sdrplay version. If this is too far off topic, maybe we can go to email.
I installed https://github.com/fventuri/nrsc5 The SDRplay version keeps losing sync. It plays for a while, then pauses to re sync. The SoapySDR version works better, but it has slight pauses when the text updates. The original nrsc5 with the rsp_tcp server doesn't do any of these things. I am running dietpi Debian Linux on a Raspberry Pi 4. You seem to be running Windows. Are you having any of these problems?
Finally settled on making the receiver selection at the top of the settings, which shows or hides the irrelevant portions. Naturally this puts an awkward space where the hidden rows are, but I can deal with that later (when I add SoapySDR, which is also supported by that version of nrsc5).
Updated nrsc5-dui.py and res/mainForm.glade accordingly. Those two will need to be re-pulled.
I am using a Raspberry Pi 4 running DietPi Debian. I have a SDRplay RSP1A. I don't know if the antenna selection is a problem with this device, as it is a single SDR. The problems mentioned in my previous post greatly improved the next day, after a reboot.
While using nrsc5-dui, I find that on most stations, it stops playing after a few minutes and does not resume. A few stations don't crash, others crash right away. These are the messages. ...na A"', '100.3', '0'] Dec 08 22:24:07 : Error creating weather map Dec 08 22:24:38 : Error creating weather map Exception in thread Thread-2: Traceback (most recent call last): File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner self.run() File "/usr/lib/python3.9/threading.py", line 892, in run self._target(*self._args, **self._kwargs) File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 985, in play self.parseFeedback(output) File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 1458, in parseFeedback self.processTrafficMap(fileName) # proccess traffic map tile File "/home/dietpi/nrsc5-dui/nrsc5-dui.py", line 1176, in processTrafficMap imgTS = imgTS.resize((imgMap.size[0], imgMap.size[1]), Image.Resampling.LANCZOS) # resize it so it's proportional to the size of a traffic map (981 -> 600) File "/usr/lib/python3/dist-packages/PIL/Image.py", line 62, in getattr raise AttributeError(f"module '{name}' has no attribute '{name}'") AttributeError: module 'PIL.Image' has no attribute 'Resampling'
Once, pressing stop, then start caused nrsc5-dui to crash, another time it played again.
Using nrsc5 from the command line is much more reliable. One station that repeatably stopped paying after a few minutes ran for hours from the command line.
@srs4511351 sounds like it could be a problem with your version of Python (I'm using 3.10) or something in the way fventuri's coding of nrsc5 that is vastly different than the original wrt to saving maps. Quite possibly the latter.
I should point out that nrsc5-dui is nothing more than a shell and precessor of what nrsc5 produces. If nrsc5 stops playing it has to do with something inside of nrsc5. That said, when you run it from a command line, you're likely not giving it the command to save maps to a folder like nrsc5-dui does. So if nrsc5 doesn't produce what nrsc5-dui expects in an image, you'll likely see trapping errors.
Have to also ask, when you built nrsc5, did you give it any architecture directives for SSE or NEON, or did you let it try to figure out which if any should be used? For example, I know on my Intel Mac I had to use the SSE directive, but on this new M1 I have to not use any directive.
I can check the version later tonight, but it would be the latest for Debian Bullseye. nrsc5-dui still stops playing when maps are not selected in Settings. All of the boxes there were deselected. I think the image error message was also present. With the original nrsc5 and the previous nrsc5-dui, the UI would slow down and appear to freeze for several seconds at a time but still played.
I specified NEON when I built nrsc5.
I should find the switches to save images from the command line and try it.
One annoying similarity with the original is a fluttering effect that sounds like a bad tape player (if you are an audiophile). There are issue tickets about this and argilo acknowledged that there is no buffering and should have. Here is a different post about that. https://github.com/theori-io/nrsc5/issues/177
Again, nrsc5 is running in it's own process. All nrsc5-dui is doing is sending it commands and trying to process what it produces. If it's not the maps, it's the other images that a station sends, such as station logos and cover art. Either way, the error you showed seemed to relate to maps.
The reason why I keep pinging on this is because the whole point of this particular project was to isolate nrsc5 and specifically the audio generation from any python routines to avoid the problems you keep bringing up, and that nrsc5-GUI (not DUI) was doing.
I do not mean to be difficult. Sorry if you thought that. I assumed what you said without a further thought. I do realize that nrsc5-dui isn't the basic application that we are using, but something is different. I have never tried nrsc5-GUI, as I thought nrsc5-DUI was more advanced. I threw in the part about the fluttering effect hoping it would hint that the fventuri/nrsc5 version works a lot like the original. I got slightly carried away in detail.
I have Python 3.9.2 Is NEON appropriate for my arm64 CPU?
Although I am getting the map files, they do not appear is the Maps tab or the maps viewer. The art files do appear in the Album Art tab.
I tried the same command line that nrsc5-dui uses. /home/dietpi/nrsc5-sdrplay/build/src/nrsc5 --dump-aas-files /home/dietpi/nrsc5-dui/aas -l2 -A "Antenna A" 100.3 0
/home/dietpi/nrsc5-dui/aas fills up with jpg, png and txt files. They are album art, station art and maps. It hasn't crashed or frozen yet.
Could you verify that the Download Album Art and Include Station Art options work? Running under nrsc5-dui, it is downloading art files regardless of the settings.
P. S. I noticed that the error messages do not coincide with playback stopping. Playback stops minutes after they appear.
There are also these initial messages: (nrsc5-dui.py:5865): Gtk-WARNING **: 00:14:58.704: Theme parsing error: gtk.css:4:28: The style property GtkRange:slider-width is deprecated and shouldn't be used anymore. It will be removed in a future version
(nrsc5-dui.py:5865): Gtk-WARNING **: 00:14:58.704: Theme parsing error: gtk.css:5:28: The style property GtkRange:stepper-size is deprecated and shouldn't be used anymore. It will be removed in a future version ['/home/dietpi/nrsc5-sdrplay/build/src/nrsc5', '--dump-aas-files', '/home/dietpi/nrsc5-dui/aas', '-l2', '-A', '"Antenna A"', '100.3', '0']
Some of this is already covered in the README...
Python 3.9 and 3.10 should be fine. I haven't tested with 3.11 yet.
nrsc5 will download any cover art and station logos that the station generates automatically into the aas folder. Any map images, if provided, go into the map folder, not aas, however defining text files will go into aas for some reason - this is a function of nrsc5 and nrsc5-dui is just displaying the images.
Sometimes the station doesn't provide album art, so the Download Album Art functionality was added to supplement this by doing a search at Musicbrainz. Depending upon your processor power and/or internet speed this may take some time and slow things down in the nrsc5-dui app, but it should never really impact nrsc5 itself. That is, unless it's impacting the processor that much. But yes, this feature works and was heavily tested a long time ago. If it's annoying you or creating a problem, recommend leaving them unchecked. For clarity: Download Album Art ignores station logos and album art provided by the station by default so Include Station Art was added to get both. Extended Queries does a deeper search in Musicbrainz, which may create additional delays as they process the query, but that will generally come up with a result if the regular setting doesn't.
I have no idea if NEON is appropriate for your processor or architecture, but the logical thing to do is to trying a clean cmake/build without any directives to see if the resulting nrsc5 is more efficient. As I mentioned, I'm running on an aarch M1 Mac and a NEON-build wouldn't work.
I can't help you with your gtk environment other than to say this app uses and expects GTK 3+, not just GTK 4. I get none of those warnings on either my Mac running the latest gtk3+ environment from homebrew, nor on my native Fedora 37 box. Both have gtk3+ and gtk4, and are using an Adwaita theme. All I get is a Cursor Theme warning on the Mac. If you're familiar with GTK, the warnings are annoying and may trigger a few OCDs, but mean absolutely nothing - especially the deprecation warnings.
I might also add: When was the last time you pulled an updated nrsc5 and built it? You referenced a 3 year old issue with it that has been long since resolved. The latest revision extends it's ability to the full complement of 8 streams, per the nrsc5 spec, and I just updated nrsc5-dui accordingly. They are also in the process of adding some previously unsupported service modes and fixing a parametric stereo issue. I am working with them on both of these.
Bottom line is that nrsc5 is constantly changing as the current maintainer is tirelessly and aggressively working on it. As such, it should regularly be checked for updates by running git pull origin master --tags at the root of the code tree and doing a clean rebuild as necessary.
I am running nrsc5 revision 9696b56, pulled and built on 11/24/2022, so it is recent, but not with the really recent updates.
With the fventuri SDRplay version of nrsc5 and the most recent version of nrsc5-dui, I am getting map files in both the aas and map directories. With the somewhat current version of the original nrsc5, SDRplay thru the rsp_tcp server, I have the same problem. Initially, traffic maps appear in the maps directory. Then they disappear are in the aas directory. There are weather overlay images there too. This may start after the PIL / images message appears.
I tried an older version of nrsc5-dui. git checkout v2.1.1 With nrsc5-dui 2.1.1, maps initially appear in the aas directory, then appear to be moved to the maps directory under another name. There are no PIL / image error messages and the audio does not stop playing, just messages like MusicBrainz image list retrieval error for id 1dad6ba1-008b-4e2e-9724-31da48b06171. I do get album and station art. I do get maps in the maps tab and maps viewer. Still the same somewhat recent version of nrsc5 with SDRplay thru the rsp_tcp server. What's different? For me, it's the nrsc5-dui version. Switching back to the newest nrsc5-dui causes the problem to return.
As for the gtk deprication errors, I brought it up as they claim that a feature being used will be removed in a future version. It isn't a problem yet, but you say don't worry, so it's OK.
https://github.com/theori-io/nrsc5/issues/177 is still an open issue and I still have the fluttering problems. https://github.com/theori-io/nrsc5/issues/261 is more recent, seems to be related and is still open. Buffering issues. If the slight garbling and fluttering are the fault of my system, I need help with that. It has always been there for me.
Absolutely no code regarding traffic or weather maps changed between 2.1.1 and 2.2.0. The images are initially staged in aas because that's where nrsc5 puts them. nrsc5-dui moves them to map after they are produced. Only the index files (TMI.txt, DWRI.txt) could possibly be left behind, but they are supposed to be deleted as well.
Traffic map images consist of a grid of 9 individual image tiles that are combined and then shrunk to size. Once the individual tiles are combined in the map directory they are deleted. So if they are getting left behind in aas, it may only appear to be moved back to aas.
Weather maps consist of a background image downloaded from the internet and the weather overlay provided from the station via nrsc5. Once the overlay is merged with a copy of the background map, the overlay file is deleted. If they are getting left behind in aas, like with the traffic maps, it may only appear as if they are being moved back.
In both cases the resulting image is sized, then overlaid with a date-time stamp.
It is not possible for any of the files to be moved from map to aas - there's no code to do it. Therefore, I can only guess there's a problem with not having enough memory to run 2.2.0. A significant amount of code and widgets were added to support the additional 4 streams that are part of the nrsc5 spec, and several stations are starting to implement more than just 4 streams.
As a result, Python's calling stack is likely getting crushed when you use 2.2.0 in concert with nrsc5, and the processing isn't progressing as expected - likely where the unusual errors are coming from, as well. Perhaps increasing memory (or swap space, if used) will solve the problem you are having.
Check that... Image.LANCZOS was changed to Image.Resampling.LANCZOS in a few of places in order to squelch a Pillow deprecation warning that was annoying the hell out of me, but that's the only thing that changed in the map routines. You can try searching and removing the Resampling. part and see if anything changes, but I kinda doubt it.