Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Radio in the browser

gnuradioworld.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: GNU Radio in the browser

#11

Post by alightsoul »

thomashabets2 wrote: post #4

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. T…

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

Re: GNU Radio in the browser

#13

Post by thomashabets2 »

alightsoul wrote: post #11
thomashabets2 wrote: post #4

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. T…

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 tool…

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.

Re: GNU Radio in the browser

#14

Post by WorldPeas »

thomashabets2 wrote: post #13
alightsoul wrote: post #11

Earlier quoted context omitted.

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 tool…

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 yo…

gio with golang is a great place to start imo

Re: GNU Radio in the browser

#15

Post by necovek »

thomashabets2 wrote: post #13
alightsoul wrote: post #11

Earlier quoted context omitted.

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 tool…

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 yo…

> 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.

Re: GNU Radio in the browser

#18

Post by ghostly_s »

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

Re: GNU Radio in the browser

#19

Post by baileynoack »

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!

Re: GNU Radio in the browser

#20

Post by sigbottle »

jcims wrote: post #2

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. 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.

Post reply on HN