Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Jeroen, The ODROID N2 integrates a quad-core ARM Cortex-A73 CPU cluster and a dual core Cortex-A53 cluster with a new generation Mali-G52 GPU. But, even with kernel 5.7.x "cat /proc/cpuinfo" reports six A53 cores processor :0 to 5 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull

Re: [Freetel-codec2] The LPCNet packaging problem...

You might want to try timing the lpc_test program to measure the pure decoding speed. If you use the 4 second wia clip and divide the clip time by the measured time you get your 'realtime' number. It has to be 1 or higher. For a Raspberry PI 3 (a53 core) it seems to be near 0.1 for both 32bit and

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi all, aarch64 or the ARMv8 architecture Not so easy. Every SoC manufacturer can choose to have SVE or not, and how big See Fujitsu here, page 15:   http://users.ece.utexas.edu/~gerstl/ee382m_f18/lectures/SVE_Seminar_UT_Rico.pdf And this is for a SuperComputer!! So, it looks, the

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi all, FreeDV on the Odroid N2 I loaded Armbian from:  https://forum.armbian.com/topic/12162-single-armbian-image-for-rk-aml-aw/ and one extra step: cp /BOOT/boot-emmc.src /BOOT/boot.scr Kernel 5.7.0-rc2-next-20200424-arm-64 then, just compiling FreeDV 2020 GUI with GCC Ver 8.3 runs at 35%

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi, On my Odroid N2 running Fedora 32 via "chroot" on Armbian, gcc -march=armv8-a+sve hello.c works without error. So, can the build script test for ARMv8 running 64bit    Armbian, kernel 5.4.35-meson64  cat /proc/cpuinfo processor : 5 BogoMIPS : 48.00 Features : fp asimd evtstrm aes

Re: [Freetel-codec2] The LPCNet packaging problem...

On Tue, Apr 28, 2020 at 8:05 AM Al Beard wrote: You can see if this supports that SBC... https://fedoraproject.org/wiki/Architectures/ARM/Installation#Arm_Image_Installer That should help take care of the "magic" stuff that needs to happen other than just dd'ing an image to an SD card. >

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi all, More progress: Odroid N2 loaded with Armbian  Copied the Fedora 32 SD card files to /fedora copied the dev entries from Armbian to /fedora/dev Now do "chroot /fedora /bin/bash" and now "dnf" works and can load apps. But the resolver doesn't work so put entries in /etc/hosts

Re: [Freetel-codec2] The LPCNet packaging problem...

Thanks Richard, I've downloaded the Fedora 32 aarch64 SD card image. Made an SD card. But, though the DTB file is there for the Odroid N2 there is no loader in /usr/share/uboot/ and no hints in /usr/share/arm-linux-installer/boards.d or /usr/share/arm-image-installer/socs.d/ I can

Re: [Freetel-codec2] The LPCNet packaging problem...

On Mon, Apr 27, 2020 at 5:35 AM Al Beard wrote: > *Hi Richard,* > > *I've looked here and only find gcc ver 9.3.1* > > * https://kojipkgs.fedoraproject.org/packages/gcc/ > * > Hmm.. I'm not familiar with that link "kojipkgs" but this one works:

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, I've looked here and only find gcc ver 9.3.1 https://kojipkgs.fedoraproject.org/packages/gcc/ Can you point me to where "10" is please? And, of course, I need the "aarch64" binary. Alan VK2ZIW On Sun, 26 Apr 2020 07:00:18 -0500, Richard Shaw wrote > On Sun, Apr 26, 2020 at 6:39

Re: [Freetel-codec2] The LPCNet packaging problem...

On Sun, Apr 26, 2020 at 6:39 AM Al Beard wrote: > > It's GCC Ver 10 that has all the smarts on optimisation. > (not yet released). > Fedora Rawhide is already on gcc 10 (Fedora is the test ground for gcc and new kernels). I should be able to setup Fedoa Toolbox which would give me a container

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi David and Bruce, arm64 testing. I've just installed Debian Buster on my Odroid N2 from: https://forum.odroid.com/viewtopic.php?t=35658 and discovered we have GCC Ver 8.3 whereas Ubuntu on the Odroid N2 has GCC Ver 7.5 so we should have some of the new instructions. It's GCC Ver 10 that has

Re: [Freetel-codec2] The LPCNet packaging problem...

ATM we only support NEON and AVX, and they belong to different architectures, so you can't build them together. However looks like SSE support is coming, thanks to Sasaono's fine work: https://github.com/drowe67/LPCNet/pull/25 which is the point where something like your suggestion will be

Re: [Freetel-codec2] The LPCNet packaging problem...

Why not combine the CPU-specific math accelerator libraries, and set function pointers at runtime? It would be fewer builds, more distro friendly, and less configuration when building from source. On Sat, Apr 25, 2020, 3:17 PM David Rowe wrote: > Hi Richard, > > Pls be careful putting too much

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, Pls be careful putting too much work into this. I estimate the actual number of people using FreeDV from a package/distro to be quite low. I'd estimate 90% of the end users run Windows, and most of the open source community build from source. For the purposes of

Re: [Freetel-codec2] The LPCNet packaging problem...

Ok, so we need a new approach... 1. Bundle (known good?) snapshots of LPCNet into FreeDV and either statically link, or at least make the library "private", i.e.: /usr/lib{,64}/freedv on RPM based systems. We can either copy it in, which I hate for one reason, or use git submodules which I hate

Re: [Freetel-codec2] The LPCNet packaging problem...

> I am seeing 'x86'. Are people really using i386 type processors, or is > this only x86_64/amd64 processors? The latter. > How new a processor do people really need? I have a machine that I > think was fairly high end in 2014: It's not so much age, as features. You need AVX. I have a

Re: [Freetel-codec2] The LPCNet packaging problem...

> Is NEON really realistic then? Or is it there because the Mozilla LPCNet > has an option for it? No I don't think so. Jean-Marc (the original LPCNet developer) and I did some NEON optimisation work to see if it would run on a Pi, but we couldn't get it to run in real time. > As far as the

Re: [Freetel-codec2] The LPCNet packaging problem...

On Wed, Apr 22, 2020 at 2:48 PM David Rowe wrote: > Hi Richard, > > > Is it possible to "kill it with hardware" with a modern CPU at this > > point? Jaroslav wants to package LPCNet for Fedora/FreeDV integration > > into Quisk. > > TBH I'm not sure. Further optimisation in this area (e.g. on

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, > Is it possible to "kill it with hardware" with a modern CPU at this > point? Jaroslav wants to package LPCNet for Fedora/FreeDV integration > into Quisk.   TBH I'm not sure. Further optimisation in this area (e.g. on the LPCNet code, other SIMB instruction sets) is possible.

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, Happy to rename it to LPCNet_freedv if that helps. Both this version of LPCNet and the source LPCNet repo it was originally cloned from are highly experimental chunks of code designed for bleeding edge DSP/neural net developers. They are not mature stand alone applications or

Re: [Freetel-codec2] The LPCNet packaging problem...

On Wed, Apr 22, 2020 at 2:22 PM David Rowe wrote: > Hi Richard, re: > > The LPCNet codec isn't usable in real time without AVX acceleration, I > can't think of a use case for loading a non-optimised version. > Is it possible to "kill it with hardware" with a modern CPU at this point? Jaroslav

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, re: > try to load liblpcnetfreedv-avx2.so > Not found? > > Try to load liblpcnetfreedv-avx.so > > ... > > Try to load liblpcnetfreedv.so (no optimizations) The LPCNet codec isn't usable in real time without AVX acceleration, I can't think of a use case for loading a non-optimised

Re: [Freetel-codec2] The LPCNet packaging problem...

On Wed, Apr 22, 2020 at 10:40 AM Danilo Beuche wrote: > Hi Richard, > > maybe two builds (one with, one without AVX2 etc.) and a wrapper program > do the job. The wrapper does nothing more than detecting what is available > and starts one or the other binary. > Similarly we could put all the

Re: [Freetel-codec2] The LPCNet packaging problem...

Hi Richard, maybe two builds (one with, one without AVX2 etc.) and a wrapper program do the job. The wrapper does nothing more than detecting what is available and starts one or the other binary. Similarly we could put all the application code in two differently builds of a dynamic library and a

[Freetel-codec2] The LPCNet packaging problem...

So LPCNet requires AVX, AVX2, or NEON, but in most Distro's those instruction sets can not be assumed. There's still hardware being produced that don't have any of those. For instance, in Fedora x86_64, we only assume up to SSE2 because assuming anything higher would prevent install on some