version 2.0.963

[ahop...@googlemail.com]

Hi All,

there are new test versions here:-

  https://www.sparksdr.com/download/SparkSDR.2.0.963.win64.zip
  https://www.sparksdr.com/download/SparkSDR.2.0.963.win32.zip
  https://www.sparksdr.com/download/SparkSDR.2.0.963.linux-x64.deb
  https://www.sparksdr.com/download/SparkSDR.2.0.963.linux-x64.rpm
  https://www.sparksdr.com/download/SparkSDR.2.0.963.linux-arm.deb
  https://www.sparksdr.com/download/SparkSDR.2.0.963.linux-arm64.deb
  https://www.sparksdr.com/download/SparkSDR.2.0.963.osx.zip

The key change is a rewrite of the audio system that should make audio more reliable  (especially on linux) and reduces cpu if multiple receivers use the same audio device.

There is initial support for the Hermes Lite IO card, frequency and rx source are sent and there is a rx source dropdown in the radio settings.

It also uses the just released V11.0 of Avalonia Avalonia UI - Home.

73 Alan M0NNB

[Steven Sostrom]

I have a Raspberry Pi 4 with 8GB of RAM with an SDRplay RSP1A SDR.

I installed SparkSDR version 2.0.963 on DietPi bookworm. 

With only the command prompt and SparkSDR running, and the sample rate at 2000K, CPU load is above 80%.

Receiving a broadcast FM signal without stereo, it sounds OK on the Pulse audio device. When I turn on stereo, audio is choppy and sounds distorted.
When playback is stopped, there are a series of ticks for a few seconds.

The ALSA devices have very choppy audio with or without stereo.

With a sample rate of 1536K, CPU load is about 85%. Audio is choppy.

786K isn't much better. At 6144K, CPU load is 88% and audio is not much worse than 2000K sample rate.

I uninstalled version 2.0.963 and installed SparkSDR version 2.0.33.
With sample rate at 2000K, CPU load is much lower at about 65% and there are few dropouts with the ALSA device, worse with the Pulse device.

Occasionally, CPU load goes higher, causing dropouts temporarily.

It looks to me that version 2.0.963 has a much higher CPU usage as compared to version 2.0.33. Audio seems to be sensitive to CPU load with either version.

Pulse is better on version 2.0.96, ASLA is better on version 2.0.33.

----Steve

[ahop...@googlemail.com]

Hi Steve,

what happens to cpu when you minimise the app?  This will indicate if it is a problem with the graphics (possibly caused by new Avalonia version). What are you measuring cpu with, some linux tools give it as a percentage of one processor core (so the max is 400%) and others give it as a percentage of total.
73 Alan M0NNB

[Steven Sostrom]

CPU load goes to 51% when I minimize SparkSDR.

I have the CPU Usage Monitor applet which only shows a graph.

The CPU usage numbers come from htop. I used the average reading, so some processors were the the 90% range.

Changing the CPU governor to keep the CPUs running at 100% drops the CPU load to about 40% with SparkSDR minimized. It doesn't help much when not minimized.

With SparkSDR minimized, I still get some audio dropouts.

[ahop...@googlemail.com]

Hi Steve,

do you have the  opengl desktop enabled, from raspi-config in the advanced menu?  

73 Alan M0NNB

[Steven Sostrom]

I booted a Raspberry Pi OS system. The symptoms are the same, with ASLA being very choppy and high CPU usage unless minimized.

However, the Pulse audio is much better, less garbled than the DietPi OS.

I do not find opengl desktop in the raspi-config Advanced menu. Can you be more specific as to the sub menu, etc.? Do I need to install a package for this to be available?

----Steve

[ahop...@googlemail.com]

Hi Steve,

just got in font of a rpi and found the option with sudo rasp-config then Advanced Options then CL Driver then select a GL option.  Might need a reboot after.

I also get best performance with the 64 bit pi os.
73 Alan M0NNB

[Steven Sostrom]

I do not have that option. Is it item A2 or A9 on the Advanced menu?

With sudo rasp-config then Advanced Options, I do not have the CL Driver. Items A2 and A9 are missing.

│   A1 Expand Filesystem       Ensures that all of the SD card is available    │
│   A3 Compositor              Enable/disable xcompmgr composition manager     │
│   A4 Network Interface Names Enable/disable predictable network i/f names    │
│   A5 Network Proxy Settings  Configure network proxy settings                │
│   A6 Boot Order              Choose network or USB device boot               │
│   A7 Bootloader Version      Select latest or default boot ROM software      │
│   A9 Wayland                 Enable experimental Wayland backend             │
│   AA Network Config          Set network configuration tool

Other opengl SDR apps have a 10% or less improvement when minimized.

Looking at the documentation, that missing raspi-config option seems to be related to the kms driver.

I have tried both of these by enabling them on at a time in /boot/config.txt

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-fkms-v3d ( I believe this is the OpenGL Fake KMS desktop graphics driver)

Neither one fixes the problem. They work in the other apps that I tried.

I normally use the fkms driver, as in the past, it fixes some audio problems and video/high CPU use problems in SDR++.

[Steven Sostrom]

I experimented further with the vc4 kms drivers.

Disabling them caused SparkSDR to have a higher CPU usage than it did previously, about 90%, when not minimized.

Moving windows appeared to be jumpy.

It also caused gqrx to have a much higher CPU usage when not minimized. It normally improves about 10% when minimized.

It looks to me like I have a better driver with vc4-fkms-v3d ( OpenGL Fake KMS desktop graphics driver).

vc4-kms-v3d has been working about the same.

----Steve

[ahop...@googlemail.com]

Hi Steve,

it sounds like you have the best driver. I'll do some testing with sdrplay on the rpi and see If I can reproduce your issue. I do have a tweak in the pipeline that significantly reduces cpu use for the display but that will take a little while.

73 Alan M0NNB

[Steven Sostrom]

I built a new system and tried several versions of Spark SDR.

SparkSDR.2.0.33 ran at about 65% average CPU usage. Any version that I have after that ran at about 80% CPU usage.

Those versions were SparkSDR.2.0.943, SparkSDR.2.0.951 and SparkSDR.2.0.963.

Maybe this helps to isolate the cause?

With SparkSDR.2.0.33, I am having problems with audio dropouts. Pulseaudio is choppy. ALSA occasionally has larger dropouts.

Playing with audio configuration settings has helped in the past, but nothing seems to help this time.

It's a bit difficult to fix because the problem is sometimes worse than other times.

[Mike G4RAA]

Hi Alan

I finally had a go with v2.0.963 Win64 and find that both the Tune & Drive controls can be set to any value, including negative ones. Works fine if you double-click on the control but not using the mouse wheel or click'n'drag. Setting drive to 256 results in no output. It seems to wrap around, so I got more or less full drive at 508.

I tried it on two different PCs, so not a one off problem.

73

Mike

G4RAA

[ahop...@googlemail.com]

Hi Mike,

good spot, It is the result of a quick fix I made for a problem introduced in Avalonia 11.0 . I shall fix my fix for the next release.

73 Alan M0NNB

[Mike G4RAA]

Hi Alan

A few more observations, hopefully useful feedback, this time about operating FT8 within SparkSDR. There are still quite a few 'funnies' so I've been using DigiU and WSJT-X but it would be useful to operate using the FT8 mode within SparkSDR, if only when /p.

• The button marked Simplex only seems provide simplex operation if you are calling CQ. If you are responding to a CQ call SparkSDR seems to hold the TX frequency whether Simplex is pressed or not. This is ok much of the time but there are times when it is preferable to change TX freq to the CQ station's freq. Rather than complicate matters you could just change the text to 'Hold TX freq' to make operation clearer.
  

• Auto seq mode seems to have a bug. I was using Answer First which initiated a QSO with the first station decoded of two calling me. Unfortunately SparkSDR then switched to the second station calling, resulting in a QSO with him in the middle of the QSO with the station I was already working.

• Which brings me to a logging issue. I was able to log the 'middle' QSO but found I couldn't log the outer one. I was able to manually enter call and signal reports but not time/date, which were fixed at 1/1/0001 00:00:00. There are times of course that you need to catch up on your logging and enter a QSO after it has finished. Not two millennia ago though!
  

• I could have sworn the buttons next to the TX macros changed colour (darkened) when active but this appears not to be the case. It would be really helpful if they did so it is clear what has been selected and is being transmitted.

• The default for the last macro of a CQ sequence should probably should end R73 (which is current usage) rather than RRR which is hardly used now. (If sending RRR I think there is supposed to be a final sequence with a 73 but that wastes a TX cycle as well as the following RX cycle so very, very few people bother with RRR anymore.)
  

Best 73

Mike

G4RAA

 

On Thursday, 6 July 2023 at 14:29:32 UTC+1 ahop...@googlemail.com wrote: