Raspberry Pi 4 and SDR Software for HL2

[Steve Haynal]

Hi Group,

This weekend I ran a few experiments running the HL2 from a Raspberry Pi 4. I wanted to see if it is possible to run 4 receivers at 384kHz (maximum bandwidth) on the Raspberry Pi 4. I tried all 4 RPi and HL2 compatible software SDRs that I know of. Here is a summary of my results:

** Raspberry Pi 4

Latest Rasbian based on Debian 10 (Buster) with kernel 4.19. I updated and upgraded all packages with apt install before testing.

** Quisk

4.1.55 built from source for python3 grabbed from https://pypi.org/project/quisk/

ALSA backend

No problems with 4 receivers at 384kHz, audio was smooth and without cracks or drops

120% CPU usage (100% is one core, the RPi4 has 4 cores, all CPU and Xorg usage is with 4 384kHz receivers)

30% Xorg usage

Forgot to make memory measurements, but memory was not a limiting factor in any of the tests

** SparkSDR

This version: https://groups.google.com/d/msg/sparksdr/198TALvyask/P-bzBKxMCgAJ

ALSA backend

No problems with 4 receivers at 384kHz, audio was smooth and without cracks or drops

140% CPU usage

5% Xorg usage (no summary waterfalls)

** LinHPSDR

April 4 pull from https://github.com/m5evt/linhpsdr

170% CPU usage

90% Xorg usage

Native ALSA backend

No problems with 2 receivers at 192kHz, cracks and drops start when total bandwidth is more than about 2X384kHz, worse as more receivers are opened

SoundIO ALSA backend

Same as above

SoundIO JACK backed

Cracks and drops were a bit worse with JACK. Adjusting the latency in JACK did not seem to make a difference. 

** pihpsdr

April 4 pull from  https://github.com/dl1ycf/pihpsdr

92% CPU usage (Could only enable 2 384kHz receivers with pihpsdr)

34% Xorg usage

Native ALSA backend

Some minor cracks and drops at 2X384 kHz receivers, better than the same with linhpsdr, but not as good as Quisk or SparkSDR

I think that the RPi 4 has sufficient horsepower to run 4 384kHz receivers, but the local audio code in the software must be tuned with care to avoid audio drops.

73,

Steve

kf7o

 

[Matthew]

Very interesting. I am puzzled by linhpsdr having a higher CPU usage, much of the core code and method is the same for linhpsdr and pihpsdr. This has puzzled me enough to buy a Pi 4 to investigate.

Over the past week I've been buried in understanding the inner workings of alsa and buffer sizes etc. I have definitely learnt a thing or two that might help with audio on slower CPUs.

In browsing the makefile for pihpsdr I noticed the hpsdrsim app that is included in the pihpsdr build. This looks very interesting. I know Alan built something similar for Windows. I have been wanting to check PureSignal works in linhpsdr but don't have the hardware to check this yet. This test app looks ideal for this. (unless any linux users have a hardware setup to test this and report back?).

73 Matthew M5EVT.

[Alan Hopper]

Hi Steve & Matthew,

I powered up my rpi4 for the first time at the weekend and was very impressed compared to the pi2 I had been using. I assumed the piHPSDR/linHPSDR cpu difference is due to the number of receivers.

If anyone wants to try SparkSDR on the rpi I reccommend the versions here http://www.ihopper.org/radio/previews.htm . There is quite a lot of scope to reduce the cpu use in spark, on arm it currently falls back to using kissfft and there are various key places where I use simd code on intel which need an arm neon version written.  I also plan an arm64 version but am procrastinating in the hope that someone else starts maintaining an arm64 build of skiasharp and harfbuzz that Avalonia (the gui toolkit I use) needs.

73 Alan M0NNB

[Matthew]

Alan,

I'm impressed by how well you manage to cross compile for different operating systems and achieve what seems to be (from my MIDI cw tests) low latency (I forgot to measure keydown to sidetone latency with Spark MIDI cw and Arduino - did you ever measure this with a scope? all I can say is I couldn't "feel" it at 30 wpm). How much OS level audio config is taken care of by Avalonia and how much requires you to delve deep to configure this for each OS?

Also, the results above certainly fly the flag for Python and the old "C is best for performance" isn't the whole story anymore (some may say it hasn't been for 20 years?).

73 Matthew M5EVT.

[Alan Hopper]

Hi Mathew,

I'm using portaudio for xplat audio, the audio never enters the c# Avalonia part of the code. I would like to drop portaudio, partly to reduce dependencies but also because it is falling behind especially for wasapi ,the latest windows version uses a tweaked portaudio to minimize latency whilst still using the audio hw in shared mode.  I tried a couple of other libaries but they again needed tweaking for low latency.  I have not tried minimising the underlying buffer size in linux yet and may try using alsa or jack directly.  As Jim said, xplat audio is a pain:)

On windows 64 the midi key to sidetone latency was under 7ms with audio in exclusive mode, I need to test again in shared mode(if I've done it right it should be the same).  I'll test on linux at the same time.

I think it is intersting that the cpu use is fairly similar between programs, it is not uncommon to see much bigger variation between similar programs.  I know how I can reduce cpu in Spark but I'm sure Jim and John would say the same. I guess low xorg usage in Spark is caused by Avalonia drawing all controls itself using the gpu.

73 Alan M0NNB

[Matthew]

I just had the scope setup on the bench for something else. While I had it out I measured the MIDI CW latency in Linux with SparkSDR. I triggered the scope on key down and with PulseAudio measured around 12 ms latency. I am estimating from a crude measurement, the Arduino MIDI interface contributes around 1.5 ms latency. This corroborates with the musicians rule of thumb that around 10 ms latency is ok for live music https://djtechtools.com/2008/09/26/is-your-midi-controller-late/

73 Matthew M5EVT.

[Alan Hopper]

Hi Matthew,

I'm pleasantly surprised the latency is that low on linux (considering I'm using portaudio defaults), is there a way to tell the underlying audio buffer size/latency for your system? I'm very tempted to replace portaudio with a direct Jack connection, Is there any downside to only supporting Jack on linux? The latency from hl key input to sidetone should only be a couple of ms worse if I've got it right.

73 Alan M0NNB

[John Williams]

Maybe it just me, but I find Jack to be almost always non-obvious and hard to configure. Alsa just works for most folks, IM

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/17ec1089-bbcb-4d7b-a9e3-8425ad0605de%40googlegroups.com.

[Roger Critchlow]

Alan --

The issues with using Jack are that people need to install, configure, launch, and connect it.  There's a substantial ecosystem of programs to help you with these tasks, but I find them inconsistently helpful.

There are two versions, jack1 and jack2, in the repos and portaudio packages have been mistakenly configured to depend on jack1 rather than either for years.  This appears to be fixed in Ubuntu 19.10 running with current and backported packages, but it's been an issue in the past year.  It's only an issue if you have reason to insist on jack1 or jack2.   

Hah, spoke too soon.  The libportaudio2 package is now configured to depend on libjack-jackd2, that is, it speciifies jack2, but the portaudio19-dev package depends on the generic libjack-dev package.  So they didn't actually fix the bad dependency, they moved from a broken config that fought with me to a broken config that leaves me in peace.  Both jack1 and jack2 use the same API so they should be interchangeable.

The installation of either version of jack pops up a dialog about granting real time configuration.  This must be answered yes, but it defaults to no.  And then you need to add yourself, and any other jack users, to the "audio" group, and then you need to reboot for the permissions granted to the group to take effect.  The command "sudo dpkg-reconfigure -p high jackd" will let you do over the real time configuration without a complete re-install.   Logging out and back in used to be enough, but it isn't enough any more.

The lack of real time configuration turns up as complaints about inability to lock memory, inability to get realtime, and inability to bridge the Alsa MIDI into jack.

Then you need to configure and launch.    I launch jack with the command: '/usr/bin/jackd -dalsa -dhw:0 -r48000 -p256 -n2 -Xraw'.  That specifies the configuration using Alsa  ("-dalsa") as the backend, using the first alsa device ("-dhw:0"), running at 48000 samples/second ("-r48000"), using buffers containing 256 samples ("-p256"), keeping 2 buffers in play ("-n2"), and bridging Alsa raw midi devices ("-Xraw").   Messages from the server will be printed to the standard output of jackd.  The possible digits after "-dhw:" can be found with the command "cat /proc/asound/cards".   The possible values for "-p" are all powers of two,  the smaller the less latency, but you need to test to decide what works.  Leave it off and I believe you get "-p1024 -n2", you can see the values used in the standard output of jackd.   It used to be that "-n3" was recommended for usb audio.  You could alternatively configure and launch using the jack_control command, or by using qjackctl, or by several other jack racks or session managers or whatever.

And finally you need to connect.  The command "jack_lsp" will list the ports active in your jack server and a variety of properties of the ports.  The commands 'jack_connect' and 'jack_disconnect' will allow you to connect/disconnect ports.   Again, you can find many other programs to help you connect jack ports together.

Qjackctl is very much the swiss army knife of jack.  I've had many good experiences with it.  But I had to give up trying to read a connection graph the other day because it was illegible as drawn.   And the qjackctl patchbay uses the same illegible bipartite graph representation, but introduces a whole new naming convention for ports, the rationale of which has escaped me for months.  So I am trying to eliminate the need for qjackctl in my work flow, but I still relapse pretty frequentlly.

So much aggravation!  Why bother?  Because when you're done you have an audio sample and event bus which solves all the hard problems of generating realtime audio in response to realtime events and of diagnosing which parts of your realtime audio processing chain are slacking off the pace.  And this works on resource limited machines, to the extent possible, so if you want to tailor your realtime chain to run on a weak RaspPi, you can build it up under jack and discover exactly what the processor can support.

But John is right, it's way non-obvious and hard to configure.  It's not a sound interface, it's a realtime audio sample and event bus.  

-- rec -- ad5dz --

[John Williams]

Alan, sounds a bit like the start of a Steven King horror book, right?

Thanks Roger!

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAGayqouU%2BLJWMnyWNKw%3D6MyvbM%3D_jus4d-ED7_38r8gRexkycA%40mail.gmail.com.

[Steve Haynal]

Hi Alan and Group,

The ~12ms latency on Linux sounds very good. I need to try it out.

You mentioned trying various audio libraries. Did you try http://libsound.io/ ? This is used by linhpsdr and provides support for JACK/ALSA/PulseAudio and other backends. I'm not sure about the latency overheads.

Although I like JACK and didn't find it too hard (~10minutes) to setup on the RPi4, it can require advanced knowledge and expertise to setup, especially if something goes wrong. I think it would be great is libsound.io or some similar library can provide support for multiple backends so everyone from beginners to experts have options.

73,

Steve

kf7o

To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite+unsubscribe@googlegroups.com.

[Matthew]

Gosh! What a question - what next? What is your preferred Linux text editor? (vim by the way).

My instant reaction would be support PulseAudio. This is installed by default on most of the popular Linux flavours I have used (I'm sure someone can claim an exception apart from the rpi). You have to go out of your way to disable the PulseAudio server and use alsa properly. Offering only alsa, I suspect you would be asking a lot of people to email you their .asound.conf files.

I really like Jack, but I think Roger provide a nice synopsis of Jack and some of the challenges. Once it is all setup and working it works really well. I've had my fair share of pain setting up Jack (granted, most of this was when Jack was less than 5 years old). But then I discovered KXstudio about 6 years ago and have had no problems since. But I only use Jack on a PC dedicated to doing music stuff. Steve provides a nice precis here for Cadence:

https://groups.google.com/d/msg/hermes-lite/Cq7dyiBru6U/JGGd6fwuAAAJ

In theory alsa should have the lowest latency compared to Jack. But some people claim this is not always true.

Linhpsdr uses soundio. This seems to work quite well and allow alsa, jack and PulseAudio to all be used within a simple interface.

73 Matthew M5EVT.

[Alan Hopper]

Hi Group,

Thanks for all the answers on linux sound, I think I'm now convinced that supporting just one is not a good idea :) I have looked at libsoundio and rtaudio in the past, none of them including portaudio have proper support for low latency shared mode wasapi. I might have another look at libsoundio as I didn't enjoy tweaking the portaudio wasapi code, maybe it will be easier to do a proper job in libsoundio. From what I can remember I gave up on rtaudio as it was not focused on low latency.

(the only editor to use on linux is to vnc to a windows box and use visual studio :))

73 Alan M0NNB