Multiple Demodulators / UI Docks Update

[LouDou]

Hi all,

Relating to:

• Feature: Multiple demodulators simultaneously #946
• Feature: Set receiver center frequency and demodulator frequency separately #945

This is the result of my playing around with Gqrx for a month or two. My primary goal here was to implement multiple demodulators, which led on to looking at how the UI would need to change to support it. I could easily go on and keep making changes, but I think I have to draw the line here and let other people see it.

All the major functions should still be working (* except one).

There's some feedback required on things like:

1. Uses new Advanced Docking System for UI docks - really flexible layout options, floating windows, groups, tabs etc.
2. Demodulator dock panel has its own toolbar for bookmarks, FFT centre, remove.
3. Keyboard shortcuts for demod and audio now need to be pre-selected using Ctrl+ and then the original shortcut key(s). Therefore can only support the first 10 demodulators (1 == 1, ..., 0 == 10).
4. Remote control can only control the first Demodulator. I didn't go as far as implementing options to switch, and the logic to possibly switch over when demodulators are added and removed would get complicated.
5. Audio playback isn't restored yet (*except this one). I had to question whether Gqrx really needs to implement this? There are many other standard .wav audio files players out there which would do the same task much better.
6. Optional de-coupling the hardware frequency from Demodulator offset. These can be now independent or linked as required. Demodulator panel now uses the CFReqCtrl for both offset and demodulation frequency.
7. Some of the main menus have moved/changed but the action keyboard shortcuts are the same.
8. Click/drag/scroll on the main FFT will affect the 'closest' demodulator.
9. DX Cluster and IQ recorder tools are now dockable.

Anyway - limitations aside, here's the new possibilities in their full glory:

Regards,
Doug

[LouDou]

I've added a commit which should fix the CI builds (missing dependency libqt5x11extras5-dev).
Also found and fixed a compile error and warning which only showed up on ubuntu 18.

[vladisslav2011]

1. Creating separate ui widget for each receiver/audio output/recorder/etc. looks like bad idea to me. It would be better to add a dropdown widget to select one receiver as current and load it's options into one set of shared widgets. The same thing may be done by clicking any receiver's marker on a waterfall... The selected receiver's marker may be idicated by drawing filled/empty triangle on top of it.
2. Adding an option to choose the marker color for each receiver may be good thing.
3. CPU load is not a big problem when using RTL-SDR, but with Hackrf/LimeSDR at maximum sampling rate things are getting much worse. I suggest putting a DFT channelizer before xlating FIR filters and adjusting filters taps to new offset frequency/sampling rate.
4. Downmixing audio streams into one for playback and adding an option to record it may be great too.
5. Adding global "autosquelch" button may help a lot as cycling through all receivers and adjustng squelch threshold after changing LNA/VGA/IF gain is really annoying.

[LouDou]

Hi @vladisslav2011 - thanks for the feedback. I have some responses ;)

1. I think we could set up the UI to handle both use cases. Personally, I prefer the receivers visible side by side. I understand you prefer them "stacked". I think we can solve your use case simply by focussing/raising the receiver panel via selection somewhere at the global level. Either on the main panadaptor or via a drop-down would work I think. In your setup, you would add all the receivers to the same dock group as tabs, then selection would just raise the correct tab for you.

2. Agree - I have thought about colour and also name customisation for the receivers

3. I'm not a DSP expert in this regard. I think I understand the optimisation, but would need some help.

4. I'm not convinced this needs to be in gqrx itself. You should be able to route the audio at the OS level into some other appliaction(s) for mixing and recording. However, I understand the convenience of keeping it in the same app.

5. Agree - I also find myself going through each receiver and audio panel trying to match the settings. Some sort of linking or global controls to set all at once would be useful.

[vladisslav2011]

1. As each receiver has at least 2 tabs visible (and 5 at most), focusing/raising multiple tabs at once looks like strange idea to me. It looks better to hide/show groups of tabs, linked to the "current" receiver. But all receiver controls will still be here wasting resources. Reusing one set of controls would be much better when running gqrx on systems like RPI or old PC. And using gqrx on relatively small monitor (not 4K or 2x4K) is uncomfortable. All these small windows quickly take up all space leaving very small area to the waterfall/panadapter. On the other hand, you have done much work...
2. OK. I have plans to try to implement lightweight multichannel receiver based on DFT channelizer/downsampler, but I have not enought time. I'll try it sometimes later. Maybe.
3. Some sort of linking (through special "global" receiver) would be great, but it requires too much work to implement... We'll have to reimplement each control and each of popup dialogs with 'sync' button/switch added. And write this switch logic: at "global" receiver control enabling/clicking the switch will cycle through all receivers, checking the same control's switch state and syncing the control's value if it's switch is enabled. And at local receiver disabling the switch/changing value should untie the control from global one. Switching it back on should copy global value to local control if global control is enabled for this value.
4. Docking system is buggy. It freezes when I try to dock a detached floating tab...
5. Setting loading is broken too. It does not redraw the window correctly if stored and current tab layouts differ.
6. When a new demodulator is added, it gets added with default settings. Maybe it will be better to copy settings (except frequency offset) from the last (current) demodulator.

[LouDou]

But all receiver controls will still be here wasting resources.

To address this point in terms of memory use; I've just run this version using valgrind/massif heap profiling tool. It appears that adding each demod takes about 18MB of heap space. In this run, I added and removed 1 demod twice. Then added 10 and removed them. Gqrx seems to take a minimum of 53MB heap, and peaked at 233.6MB. Dividing the difference comes out at 18MB per demod. This also seems to be the same as the initial increases 51-68 and 53-71 (give or take rounding errors).

---

Comparing with v2.14.6 - using a peak total about 51MB with its single demodulator.

---

UX and screenspace use are of course different concerns. I''ll have a play about regarding other ways to use and/or organise the docks.

[LouDou]

Here's a bunch of screenshots of this branch running on a vanilla Debian VM with 1 core and 1GB RAM at 800x600 resolution.

• 4 Demods are running quite comfortably with regards to CPU and memory
• Screenspace is tight. I think even the original 2.14.x versions will have this same issue to be honest.

It's possible the frequency controls size can be reduced by a font point or two ?

---

Here's 2.14.x on the same VM. When docks are opened left and right, it is not even possible to see them both at once. I even had trouble trying to even get the Input and FFT docks on the left hand side. The original Qt docks are not even completely well behaved.

[LouDou]

Implemented a toggle to hide/show the demodulator settings, leaving only the offset/freq/meter visible. With the properties hidden, you can stack 2 demods vertically or horizonally on 800x600

[LouDou]

This discussion I think is getting quite long and there are still multiple items to address and discuss.

To make this much easier to manage, I've opened a Project on my fork: https://github.com/LouDou/gqrx/projects/1

It seems like the Project cards cannot have their own comment threads, but I'll try to keep it in sync with what's being discussed here.

[xsnrg]

Are there any updates?

[LouDou]

@xsnrg I think at this point it's unlikely this will be merged. I undertook a rather large set of changes to the code to achieve this, and at the time it was received with some criticism and I didn't have the inclination to push it through. Also at the time some other unrelated changes were happening which were in conflict with mine, and it turned out to be too much work to resolve those together and I gave up.

That said, the fork I worked on should still be buildable and work as-is, even if it doesn't have any of the gqrx changes made since Nov 2021. https://github.com/LouDou/gqrx