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 libraries and are not intended for general, stand alone use in binary forms. The sort of person who wants to use them directly is most likely to pull the code from Git and build it themselves. The the only use case we have is to provide a .so to link with freedv-gui - and that only on x86. It can be considered tightly coupled with freedv-gui, and perhaps distributed that way rather that a separate package. Perhaps the question is not "how to package" LPCNet_freedv across multiple architectures but "should we package it" at all? Cheers, David On 23/4/20 12:57 am, Richard Shaw wrote: > 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 processors still > in production (and may more still in use). > > Between all the architectures on Fedora (x86_64, i686, armv7hl, aarch64, > ppc64le, and s390x) there is only one baseline that meets the > requirements of LCPNet: > > aarch64 because NEON is "baked in". > > There are ways to detect the available instruction sets during runtime: > > https://github.com/google/cpu_features > > But I know I don't have the knowledge how to implement this > dynamically (at run time instead of build time). > > There's also a problem we've briefly discussed before, should we keep > the name LPCNet for our library? From a packaging perspective it's an > issue because someone may want to package the canonical LPCNet: > > https://github.com/mozilla/LPCNet > > And two packages can't have the same name for obvious reasons... > > Thoughts? > > Thanks, > Richard > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
