Quote from: Bas ON5HB on 05 Nov 2025, 15:41 We use Ubuntu Jammy 22.04 not 24.04 as we had more problems.

I tried to recreate your playback problem but don't have it.

http://websdr.heppen.be see if mine has it too for you.

Could be your browser, I use Firefox.

I use both, Firefox and Chrome, both with the same behavior. And the bug does not occur with your instance. That is Jammy, right?

Quote from: Bas ON5HB on 05 Nov 2025, 15:41 BTW, Jammy LTS will not end before Apr 2027, and total support stops Apr 2034, long time to go and work out the problems.
There is no need to use the lastest version, as this is Linux not Windows

That period is only for certain flavors of Ubuntu and for certain components like main and restricted. If you are running Kubuntu like I do, then all your desktop packages are already out of support (3 years, ended in April 2025). Same holds for the universe and multiverse components.

We use Ubuntu Jammy 22.04 not 24.04 as we had more problems.

I tried to recreate your playback problem but don't have it.

http://websdr.heppen.be see if mine has it too for you.

Could be your browser, I use Firefox.

BTW, Jammy LTS will not end before Apr 2027, and total support stops Apr 2034, long time to go and work out the problems.
There is no need to use the lastest version, as this is Linux not Windows

I just tested it under Debian stable (trixie): same behavior as under Ubuntu 24.04 - playback stops in FM mode after switching frequency.

CPU based isn't fast enough. I tried on an AMD Ryzen 8 core, it could not do what an old GPU can.
FM is a very difficult mode for SDR as it's not audio-based.

Quote from: Bas ON5HB on 30 Oct 2025, 14:49 Are you running a desktop at the same time? As we saw other problems reported with using Radeon+OpenCL+Desktop.

Yes. But how could that interfere also with the purely CPU-based processing without OpenCL?

Sorry, I do not have a publicly reachable server. I am running it locally.

Link to test it?

Are you running a desktop at the same time? As we saw other problems reported with using Radeon+OpenCL+Desktop.
Therefor most of us use Intel with internal GPU. Gen6 or newer series.

Dear all,

I am currently experimenting with an alternative squelch implementation and would like to kindly ask you for your feedback, before I send a pull request to Steven:

https://github.com/cborss/frontend/tree/main

This fork contains the following changes to the frontend:

1) The "SQ" button no longer enables/disables the squelch but sets it slightly above the current noise floor. This reproduces the behavior of the OpenWebRX squelch button, that I like so much that I don't want to miss it.

2) I replaced the first order auto-regressive smoothing filter by a short maximum (rank order) filter, that results in constant opening/closing times of the squelch. In the current implementation, the exponential smoothing results in longer closing times with longer noise tails for stronger stations. Since I prefer a shorter closing time that is independent from the signal level, I simply use the maximum value of the last N power values.

What do you think? Do we need different time constants (filter lengths) for different demodulators (short for FM, long for AM/SSB/CW)?


Best regards,
Christian (13RF7373)

It is a Radeon RX 6700 XT. But it also happens with CPU processing.