FreeDV 1.8.7 on aarch64 misses 2020 modes

[Al Beard]

Hi Mooneer and all,

The aarch64 ARM architecture on the latest 64bit ARM SBCs
being armv8 architecture has NEON as part of "asimd".
This is mandatory in "armv8".

So, in:
LPCNet/CMakeLists.txt: execute_process(COMMAND grep -c "neon"
/proc/cpuinfo

Will not find the required "neon" as in the "armv7" architecture.
Perhaps:
uname -p
aarch64

Would be better.

---------------------------------------------------
Alan VK2ZIW
Before the Big Bang, God, Sela.
OpenWebMail 2.53, nothing in the cloud.

[Mooneer Salem]

Hi Alan,

Depending on the compiler in use, it's possible that it's not actually necessary to explicitly include NEON. For instance, I recall there being warnings on macOS regarding the NEON flags not being used.  In fact, I just googled and found https://stackoverflow.com/questions/29851128/gcc-arm64-aarch64-unrecognized-command-line-option-mfpu-neon that confirms that special flags aren't needed.

Additionally, the FreeDV application itself uses a different test for non-Intel architectures to determine suitability to run 2020 mode (effectively whether decoding a random 1 second audio sample can happen faster than 2x real time). So far, I haven't heard of the current crop of SBCs being able to do this, but the ARM Macs and a few of the systems that can run Windows for ARM can from what I recall. However, if you do happen to find an SBC that can comfortably run 2020, please let us know.

Thanks,

-Mooneer K6AQ

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230203031706.M82996%40unixservice.com.au.

[Al Beard]

Hi Mooneer and all,

I've acquired an Odroid M1 SBC which has the RK3568 SOC which is armv8 and an NPU on the SOC.

And am running Ubuntu on an NVMe memory M2 board.

Also I found Manjaro (arch) supports this SBC.

(M1, M2 it gets confusing)

Alan VK2ZIW

On Thu, 2 Feb 2023 23:41:17 -0800, Mooneer Salem wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/CAAzDfxNX1z%3D%3DP05rsCmvCHSst87fFs__LxYOupd7gxSG2f7KOA%40mail.gmail.com.

[Al Beard]

Replying...

In the PC running Fedora 34 x86_64 we have 5 secs of audio "wia.wav".

date && sox ../../wav/wia.wav -t raw -r 16000 - | ./lpcnet_enc -s | ./lpcnet_dec -s > /dev/null; date

Sun Feb  5 03:13:11 PM AEDT 2023 start

Sun Feb  5 03:13:12 PM AEDT 2023 end

So, on 

Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz we do the encode and decode in under 2 secs.

bogomips : 7200.00

So far, on the ARM64 Odroid M1 running Manjaro with kernel 6.1.2

BogoMIPS : 48.00   <--- is this the same bogomips?

Sun 05 Feb 2023 15:11:40 AEDT start

Sun 05 Feb 2023 15:11:49 AEDT end

9 secs to do both encode and decode of 5 secs of audio.

Obviously some optimization is needed!

I had thought SIMD was turned ON in LPCNet, by me.

Alan VK2ZIW

On Fri, 3 Feb 2023 17:59:47 +1000, Al Beard wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230203075358.M42884%40unixservice.com.au.

[Al Beard]

So, is the aarch64 "neon" code in LPCNet truly optimized? 

On looking at code examples https://stackoverflow.com/questions/74968311/c-code-run-slower-when-simd-instructions-are-used

I see the type "union" used so the compiler does't have to "type" convert.

Where am I going?

To make portable operation practical, we need to have all Codec modes, 700D and E and 2020x

all runnable on the Raspberry Pi 4 (and better) SBCs.

Hence, I'm 'having a go' with a Rockchip RK3568 based Odroid M1 board.

Do we have any experts out there in SIMD coding?

Alan VK2ZIW

On Sun, 5 Feb 2023 14:37:30 +1000, Al Beard wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230205041946.M13886%40unixservice.com.au.

[Mooneer Salem]

Hi Alan,

FYI, the benchmarks at the most recent PR on this topic (https://github.com/drowe67/LPCNet/pull/51) may be of use. Currently the LPCNet code as used by Codec2 can decode in just about 1x real time on the Raspberry Pi 4B. However, that's still not sufficient IMO as non-real time operating systems tend to have other things going on; thus, freedv-gui requires at least 2x real-time to enable 2020 mode.

Thanks,

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230205202426.M96112%40unixservice.com.au.

[Al Beard]

Hi,

Board: Odroid M1 with RK3568 SOC and 8Gb memory, 64Gb SD card 

On Manjaro (arch derivative) in FreeDV GUI, when one chooses, under Mode, the "Other" modes

one can select 700C but anything under that is masked by the  Start Split Analog menu.

Then I stopped and started, FIXED, the Start Split etc. appeared at top RHS and Others:

are now accessible.

And the CPU usage is spread among the four cores and is always below 40%.

Lots of messages on the terminal:

txRxThread: timeout while waiting for CV, tx = 0

Encouraging.

Alan VK2ZIW

On Mon, 6 Feb 2023 09:08:27 -0800, Mooneer Salem wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/CAAzDfxP%2BMAzqVC6zmj66EPQJwZCacfmgEr3UuL0vJD-HMXiYCg%40mail.gmail.com.

[Mooneer Salem]

Hi Alan,

The "timeout" messages may be something that can be ignored, though it depends on whether the sample files decode okay for you. If there's stuttering or other abnormalities, then those messages may indicate a potential performance issue. Something that may help on slower systems is to uncheck the "Use single thread" option in Tools->Options->Modem to allow better utilization of all available cores for decoding (or alternatively, disabling multiple receive entirely).

Thanks,

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230207113306.M14341%40unixservice.com.au.

[Al Beard]

Hi,

We need a portable platform for ALL codec2 modes including the 2020 modes.

So, I acquired the Odroid M1 and loaded Manjaro, an "arch" derivative on a 64Gb SD card.

Audio devices to/from radio: Behringer UCA-202 which has Line-Out to RCA connectors.

Mic and speaker: C-Media USB for mic, HDMI for speaker.

Bugs so far:

Speaker out to the C-Media USB device gives heaps of errors, hence trying the HDMI 

Headphones on the VOLANS HDMI to VGA adapter.

Today:

Compilation, out of the box, from "./build_linux.sh pulseaudio" worked straight away.

(after loading the build system)

Playing the 2020 file appeared not successful to HDMI audio out, clear audio but bitsy, 1/4 sec gaps.

Transmission in 2020 mode was successful to my Intel Linux PC here.

And in 700 modes to my "freebeacon" here.

The available Ubuntu for the Odroid M1 has library issues so was abandoned for Manjaro.

0x73

On Tue, 7 Feb 2023 11:30:45 -0800, Mooneer Salem wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/CAAzDfxNxya3q1eSGCJGEqVazs4KhDAL6XsitOH5JgEdrtVrvUg%40mail.gmail.com.

[Mooneer Salem]

Hi Alan,

Thanks for the testing! At first glance, the cutouts seem to be an indication that the Odroid still isn't powerful enough (and/or Codec2 not optimized enough yet) for the 2020 modes. Transmit always uses a lot less CPU power than RX, so it's no surprise TX worked fine. 

Anyway, I feel like the FreeDV application should have disabled the ability to use 2020 mode given your experience. Can you wipe your configuration to defaults (Tools->Restore Defaults or delete ~/.freedv) and restart from the terminal? That should produce some timing output that would be useful to have. Some other stuff you can try:

1. Disable multiple receive support (Tools->Options->Modem and uncheck "Simultaneously Decode All HF Modes").

2. Enable use of multiple threads for multiple receive (uncheck "Use single thread for multiple RX operation" in the same Modem tab).

Thanks,

-Mooneer K6AQ

To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230210234539.M25873%40unixservice.com.au.

[Al Beard]

Hi all,

Today I emailed Jean-Mark Valin and found he did some work and published this paper:

https://jmvalin.ca/papers/improved_lpcnet.pdf

This DOES give us a method, a new vocoder/decoder that can make the 2020 modes (LPCNet)

work with the SBCs (Small Board Computers), ARM based that are available today.

Such as the Banana PI M5 or Odroid N2, N2+ or M1 and perhaps many more and mobile phones.

What say we get cracking on this as an interim "standard", allowing decode on mobile phones.

Alan VK2ZIW

------- End of Forwarded Message -------

[Al Beard]

Hi all,

Compiling Jean-Mark Valin's LPCNet code on an Odroid M1 board with the

correct CPU switch to the C compiler, is now getting close to where the FreeDV

application is usable.

The LPCNet decode process on the ARM cortex-a55 core for a 5 second input file

takes 5 secs to decode it.

So, we need to split out every second OFDM received packet and put it to a separate

decode process thus using two CPU cores of the four cores available in quite a few

current ARM SoCs.

A Codec2 repeater (as I've implemented) does not need to decode the digital data

in real time, so I could have a go at implementing the 2020 modes.

Here is an example of mode 700D on 18118KHz.

His voice digital data was retransmitted for him to listen too. (decoding at his end)

Just as is done with DMR, Fusion and D-Star repeaters.

0x73

Alan VK2ZIW

On Tue, 28 Feb 2023 17:24:07 +1000, Al Beard wrote

> To view this discussion on the web visit https://groups.google.com/d/msgid/digitalvoice/20230228071058.M4369%40unixservice.com.au.