I've been meaning to make a "GNU Radio in the Browser" (well, gnuradio-companion-like) for my RustRadio project to build flowgraphs without coding, but not gotten to it yet.
With wasm, I see a future where the browser and thus web technologies are a UI toolkit for a Linux desktop environment. It already is, people hardly use GTK and qt anymore except for desktop environments or embedded like on cars due to performance limitations. It would be cursed to see a browser running within a browser. But then replacing a desktop environment might be the limit of replacing GTK qt and other UI toolkits with web technologies, making it unnecessary and opposite to the reason people use Linux which is performance
I agree. Browser APIs don't have as much coverage as native APIs, but I would say that by far most UIs should be in the browser nowadays.
Quake can run in the browser, so in my opinion so can the likes of Photoshop. Maybe the latest AAA game is a different beast, but that's a tiny edge case.
Websites instead of apps on mobile is something that basically always sucks, but I don't see the same on desktop.
Just build your UIs in WASM already. :-)
> It would be cursed to see a browser running within a browser
> Websites instead of apps on mobile is something that basically always sucks
I find it's the opposite: on my computer, I want native apps, but on the phone, it is very hard to manage a large collection of single use apps because I do not have a keyboard to quickly navigate between them.
This is super cool! It reminds me of MaxMSP and really takes me back to some signal processing classes. The GUI is pretty nice to interact with. I'll definitely be playing around with this some more, awesome project!
No idea what I'm looking at, it's just combining some noise and a sawtooth wave to create pretty visuals I guess? if this is meant to serve as an introduction to the project it's not really succeeding. The "Description" isn't even readable despite most of the page being used for empty space. I guess it's expected to have no audio output? I presume the real purpose of this is to process signals from an actual radio?
The "Help"->"Help" menu item is notably unhelpful:
> For questions, comments, or suggestions, you can email support@gnuradioworld.com, join the Discord server, or post a GitHub issue.
"Help"->"About" at least starts to clarify some things:
> GNU Radio, entirely in your browser — explore the open-source SDR ecosystem with zero install!
> GNU Radio World is a browser-based GNU Radio Companion flowgraph editor and WebAssembly runtime. You can place, connect, and configure blocks, then run the resulting flowgraph directly in your browser.
> It is designed to download only the WebAssembly modules corresponding to the blocks you use. This on-demand architecture keeps the initial download small and can support a limitless collection of out-of-tree modules (OOTs) in the future.
> GNU Radio World also includes a collection of real RF recordings that are downloaded only when you use them. You can inspect the recordings in the built-in recording view, adapted from IQEngine, and use them in the included flowgraph examples, allowing OOTs to be shown off with real recordings of the corresponding signals
I tinkered with gnuradio back when rtl-sdr just took off (2012ish?).
I had no background in dsp or signal processing and found it so opaque as to be unusuable, even though I saw more skilled folks do amazing things with it.
At the end of the day, DSP is a lot of math and a lot of hardware. A lot of GNU Radio's code is a monster unification of so many different choices into certain interfaces (or duplication of the same choices) for, presumably performance reasons? Or just keeping every single DSP technique ever in the God Library for the super power greybeard to use.
If you have a certain DSP goal in mind (say, RF comms), and you want to do stuff but not absolutely balls-to-the-walls processing (at that point, presumably you'd move to hardware), you can design your stack in fairly modular and composable ways.
In a software context, you can decompose the abstractions fairly cleanly. You won't get 5G high performance networking but you can get good enough results.
I've tinkered with SDR some and did a bit professionally. I always found GNU Radio to fall into the uncanny valley - too GUI to scratch my programming itch but too low-level to be useful for exploration. Between libraries like `pyrtlsdr` and desktop apps like `sdrangel`, I can't seem to find a niche for GNU Radio.
I worked with GNU Radio quite a bit at one point a decade+ ago, even writing a custom C++ block, but I almost exclusively used it via Python rather than the GUI toolkit. I found it much quicker to mess around with flow graphs in code than their various UI frameworks, spawning windows as needed when plotting waveforms / spectra etc. The GUI as you said was too cumbersome.
I understand that they were trying to make a pretty complicated topic more approachable, but I always felt the push to GUI was misguided. Maybe they would have had more luck embracing the “S” in “SDR” and making programming languages the primary development paradigm.
I have to say having just done a very tricky project with a long DSP pipeline in gnuradio, that LLMs are a godsend for getting up to speed on gnuradio blocks. I too found it historically impenetrable, but was able to get a pipeline completed. That said, prepare yourself for a lot of debugging and work to diagnose problems if you’re doing anything of sufficient complexity.
Run through pysdr[0], which I found has the right complexity gradient and the right levels of abstraction for people with technical chops but who aren’t familiar with SDR
Oh that's cool!
I've set off time to blog about getting my broadband RF scanner (connecting to USRP B200 via WebUSB) to work in WASM.
https://rf-survey.habets.se/
It's basically https://blog.habets.se/2026/08/Broadband-RF-scanner-revisite..., but in the browser.
I also have an AX.25 decoder (https://thomashabets.github.io/ruwasm/) and plain old FM receiver (https://cement.retrofitta.se/tmp/rtlsdr-fm/) already. The latter two work with RTL-SDR, also via WebUSB, so no software installs or setup required.
I've been meaning to make a "GNU Radio in the Browser" (well, gnuradio-companion-like) for my RustRadio project to build flowgraphs without coding, but not gotten to it yet.
With wasm, I see a future where the browser and thus web technologies are a UI toolkit for a Linux desktop environment. It already is, people hardly use GTK and qt anymore except for desktop environments or embedded like on cars due to performance limitations. It would be cursed to see a browser running within a browser. But then replacing a desktop environment might be the limit of replacing GTK qt and other UI toolkits with web technologies, making it unnecessary and opposite to the reason people use Linux which is performance
I agree. Browser APIs don't have as much coverage as native APIs, but I would say that by far most UIs should be in the browser nowadays.
Quake can run in the browser, so in my opinion so can the likes of Photoshop. Maybe the latest AAA game is a different beast, but that's a tiny edge case.
Websites instead of apps on mobile is something that basically always sucks, but I don't see the same on desktop.
Just build your UIs in WASM already. :-)
> It would be cursed to see a browser running within a browser
It's been done.
> Websites instead of apps on mobile is something that basically always sucks
I find it's the opposite: on my computer, I want native apps, but on the phone, it is very hard to manage a large collection of single use apps because I do not have a keyboard to quickly navigate between them.
gio with golang is a great place to start imo
This is super cool! It reminds me of MaxMSP and really takes me back to some signal processing classes. The GUI is pretty nice to interact with. I'll definitely be playing around with this some more, awesome project!
No idea what I'm looking at, it's just combining some noise and a sawtooth wave to create pretty visuals I guess? if this is meant to serve as an introduction to the project it's not really succeeding. The "Description" isn't even readable despite most of the page being used for empty space. I guess it's expected to have no audio output? I presume the real purpose of this is to process signals from an actual radio?
The "Help"->"Help" menu item is notably unhelpful:
> For questions, comments, or suggestions, you can email support@gnuradioworld.com, join the Discord server, or post a GitHub issue.
"Help"->"About" at least starts to clarify some things:
> GNU Radio, entirely in your browser — explore the open-source SDR ecosystem with zero install!
> GNU Radio World is a browser-based GNU Radio Companion flowgraph editor and WebAssembly runtime. You can place, connect, and configure blocks, then run the resulting flowgraph directly in your browser.
> It is designed to download only the WebAssembly modules corresponding to the blocks you use. This on-demand architecture keeps the initial download small and can support a limitless collection of out-of-tree modules (OOTs) in the future.
> GNU Radio World also includes a collection of real RF recordings that are downloaded only when you use them. You can inspect the recordings in the built-in recording view, adapted from IQEngine, and use them in the included flowgraph examples, allowing OOTs to be shown off with real recordings of the corresponding signals
I tinkered with gnuradio back when rtl-sdr just took off (2012ish?).
I had no background in dsp or signal processing and found it so opaque as to be unusuable, even though I saw more skilled folks do amazing things with it.
*scratches head*
Might give it another go.
At the end of the day, DSP is a lot of math and a lot of hardware. A lot of GNU Radio's code is a monster unification of so many different choices into certain interfaces (or duplication of the same choices) for, presumably performance reasons? Or just keeping every single DSP technique ever in the God Library for the super power greybeard to use.
If you have a certain DSP goal in mind (say, RF comms), and you want to do stuff but not absolutely balls-to-the-walls processing (at that point, presumably you'd move to hardware), you can design your stack in fairly modular and composable ways.
In a software context, you can decompose the abstractions fairly cleanly. You won't get 5G high performance networking but you can get good enough results.
New textbook may help
https://www.gnuradio.org/news/2025-01-29-gnuradio-textbook/
I've tinkered with SDR some and did a bit professionally. I always found GNU Radio to fall into the uncanny valley - too GUI to scratch my programming itch but too low-level to be useful for exploration. Between libraries like `pyrtlsdr` and desktop apps like `sdrangel`, I can't seem to find a niche for GNU Radio.
I worked with GNU Radio quite a bit at one point a decade+ ago, even writing a custom C++ block, but I almost exclusively used it via Python rather than the GUI toolkit. I found it much quicker to mess around with flow graphs in code than their various UI frameworks, spawning windows as needed when plotting waveforms / spectra etc. The GUI as you said was too cumbersome.
I understand that they were trying to make a pretty complicated topic more approachable, but I always felt the push to GUI was misguided. Maybe they would have had more luck embracing the “S” in “SDR” and making programming languages the primary development paradigm.
I have to say having just done a very tricky project with a long DSP pipeline in gnuradio, that LLMs are a godsend for getting up to speed on gnuradio blocks. I too found it historically impenetrable, but was able to get a pipeline completed. That said, prepare yourself for a lot of debugging and work to diagnose problems if you’re doing anything of sufficient complexity.
Run through pysdr[0], which I found has the right complexity gradient and the right levels of abstraction for people with technical chops but who aren’t familiar with SDR
[0] https://www.pysdr.org/
This is so cool! Congrats!
That’s amazing, thanks for the share! I did a small test, it works, screen is a bit harder to navigate on small screens but not an issue.
Cool. On github forked and starred. Thank you.
Please don't use "fork" as a bookmark, it's quite annoying.