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.
If you are on an iPhone you can add a website to the Home Screen and it functions as a dedicated app essentially and the opened instance is treated separately from safari
Uhm, I am saying that I do not want a 100 apps (website-based or native) on my phone because this is hard to manage without better human-computer interfaces like a big screen and physical keyboard.
So I am not sure how making a web page into an app actually helps me?
When they are a web page I frequent, typing a few letters in the browser URL bar gives me the URL to click on and get there.
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.
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.
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. The field is pretty mature and the techniques just work.
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.
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
That's certainly handy... here's a simple audio frequency shifter I threw together[1].
First it takes the audio from your microphone. It then feeds it through a Hilbert transform to convert incoming audio into an IQ (complex) format. The advantage of an IQ signal format is that when you multiply it by another signal, the frequencies add or subtract, without getting extra image frequencies. This is why it's worth doing twice the computation in DSP work.
Then your audio is multiplied by a cosine wave with a frequency determined by a GUI slider, from -2000 to 2000 Hz.
This has the net effect of raising or lowering the pitch of your voice, like tuning in a single sideband transmission on ham radio.
To get the results out to the speakers, it samples only the real component to send to the audio output.
The net effect is it can raise or lower the frequency of your voice.
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!
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.
> open source solutions … centering on browsers
https://hn.algolia.com/?query=Igalia%20comments%3E5&sort=byD...
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.
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.
So I am not sure how making a web page into an app actually helps me?
When they are a web page I frequent, typing a few letters in the browser URL bar gives me the URL to click on and get there.
http://retrofitta.se/
retrofitta
Definition
Add (a component or accessory) to something that did not have it when manufactured.
What did you think it meant?
[EoF]
Strålande! Well done :)
"Fitta" is sort of like "cunt" in Swedish & .se is the TLD of Sweden.
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 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.
https://www.gnuradio.org/news/2025-01-29-gnuradio-textbook/
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.
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. The field is pretty mature and the techniques just work.
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.
[0] https://www.pysdr.org/
First it takes the audio from your microphone. It then feeds it through a Hilbert transform to convert incoming audio into an IQ (complex) format. The advantage of an IQ signal format is that when you multiply it by another signal, the frequencies add or subtract, without getting extra image frequencies. This is why it's worth doing twice the computation in DSP work.
Then your audio is multiplied by a cosine wave with a frequency determined by a GUI slider, from -2000 to 2000 Hz.
This has the net effect of raising or lowering the pitch of your voice, like tuning in a single sideband transmission on ham radio.
To get the results out to the speakers, it samples only the real component to send to the audio output.
The net effect is it can raise or lower the frequency of your voice.
[1] https://gnuradioworld.com/#fg=H4sIAAAAAAAACsVXS2_bOBC--1fMTR...