jgaeddert / liquid-dsp Goto Github PK
View Code? Open in Web Editor NEWdigital signal processing library for software-defined radios
Home Page: http://liquidsdr.org
License: MIT License
digital signal processing library for software-defined radios
Home Page: http://liquidsdr.org
License: MIT License
Looks like the current release (1.2.0) is not MIT license. Would it be possible to create a new release?
If you could bump the 1.2.x version on feature commits it'd be helpful during compilation so that it can detect whether things new things like FSK modem are available and provide an out-of-date warning.
Thanks!
Hi,
I am having the following problem when running ./configure under Cygwin:
./configure: line 4571: syntax error near unexpected token `no,,'
./configure: line 4571: `AX_GCC_ARCHFLAG(no,,)'
Can you please advise?
Thanks,
-Mihai
PS: I'm getting the same on Ubuntu 15.10.
Tried to build on an old core2duo machine. configure
did not add the right -march=core2
flag so SIMD extensions failed to build.
Had to do. export CFLAGS="-march=core2"
before running configure. Then it built ok.
Hi i need to compile library with -m32 flag and then valgrind:
`vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==19838== valgrind: Unrecognised instruction at address 0x8050599.
==19838== at 0x8050599: fft_create_plan_mixed_radix (fft_mixed_radix.c:105)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== by 0x80504E8: fft_create_plan_mixed_radix (fft_mixed_radix.c:86)
==19838== by 0x804AF85: fft_create_plan (fft_common.c:127)
==19838== Your program just tried to execute an instruction that Valgrind
==19838== did not recognise. There are two possible reasons for this.
==19838== 1. Your program has a bug and erroneously jumped to a non-code
==19838== location. If you are running Memcheck and you just saw a
==19838== warning about a bad jump, it's probably your program's fault.
==19838== 2. The instruction is legitimate but Valgrind doesn't handle it,
==19838== i.e. it's Valgrind's fault. If you think this is the case or
==19838== you are not sure, please let us know and we'll try to fix it.
==19838== Either way, Valgrind will now raise a SIGILL signal which will
==19838== probably kill your program.
`
It's probably connected with SSE4 (http://stackoverflow.com/questions/7875485/valgrind-unhandled-instruction-bytes-error). Can I turn it off and how, I try to change config.h but it's ineffective.
Hi,
I know that 4FSK is in experimental stage right now and is not available as modulation type in framing module. Is it possible that I may add it to framing easily? What all steps are required ?
Thanks
It would be nice if liquid-dsp would be able to modulate/demodulate GFSK signals.
What do you think about it?
The GMSK modulator loses accuracy over time (many hundreds of thousands of symbols) due to the fact that _q->theta
is a float and only accumulates. The phase should probably wrap locally to avoid getting very large accumulations.
https://github.com/drtyhlpr/ble_dump
I have tried this on Raspberry Pi 3. The processing speed does not seem fast enough to capture a packet since it keeps emitting "OOOOOO" message. Similarly I tried FM radio receiver on Raspberry Pi 3 and it had similar problems.
Is it doable of implementing a BLE, WIFI, GSM, LTE scanner using liquid-dsp to be deployed in Raspberry Pi 3? At this stage I am mainly interested in BLE. The output should be able to be displayed using wireshark.
The output of the above repository on ubuntu is good enough at this stage.
I cannot install because of this; aclocal,autoconf,autoheader not found...
clone was good make it
what can I do?
While running the bootstrap.sh file the following files are missing:-
aclocal
autoconf
autoheader
The following function can not find in liquiddsp,why?
spgramcf_create_kaiser
spgramcf_accumulate_psd
spgramcf_write_accumulation
Tried to build it for BeagleBoneBlack which has Cortex A8 and NEON support.
Currently https://github.com/jgaeddert/liquid-dsp/blob/master/configure.ac has such hardcoded configuration for ARM:
arm*)
# TODO: check for Neon availability
# ARM architecture : use neon extensions
MLIBS_DOTPROD="src/dotprod/src/dotprod_cccf.neon.o \
src/dotprod/src/dotprod_crcf.neon.o \
src/dotprod/src/dotprod_rrrf.neon.o \
src/dotprod/src/sumsq.o"
# TODO: check these flags
ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon";;
*)
For BeagleBoneBlack
ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon";;
must be changed to
ARCH_OPTION="-ffast-math -mcpu=cortex-a8 -mfloat-abi=hard -mfpu=neon";;
Not sure what is correct for new 4 core RaspberryPi. I got some hints that this should work with gcc >= 4.9
ARCH_OPTION="-ffast-math -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4";;
As comments are already saying, question is how to detect if NEON is supported and which neon flag to use, the same goes for mcpu flag.
Despite the known fact that liquid-dsp does not build with LLVM/Clang (documented in the troubleshooting section), building liquid-dsp on a specific version of Mac OS X does fail with multiple errors like:
{standard input}:25:no such instruction: `vmovss LC1(%rip), %xmm2'
Currently the full error log available at: http://bot.brew.sh/job/Homebrew%20Core%20Pull%20Requests/4200/version=mavericks/testReport/junit/brew-test-bot/mavericks/install_liquid_dsp/
I don't know why this only happens on Mavericks (10.9.x) while building on Yosemite (10.10.x) and El Capitan (10.11.x) does work flawlessly when building with GCC instead of LLVM/Clang.
Possible fix:
By adding the compiler flag -Wa,-q
this issue can be resolved while it also works on newer versions of Mac OS X. This was suggested as a solution for a similar issue OP2/PyOP2#471 and this thread on StackOverflow.
Note:
I came across this bug while submitting a package for Homebrew (third party package manager for OS X). The corresponding pull request is Homebrew/homebrew-core#2664
Update: This only affects version liquid-dsp 1.2.0 when building with GCC instead of LLVM/Clang
I run ./bootstrap.sh and ./configure , and they all succeed.
when run make, it shows:
andy@andy-Mac-Laptop:~/liquid-dsp$ make
gcc -I . -I include -Wall -fPIC -g -O2 -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed
make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1
src/math/src/poly.findroots.c:287:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
if (isnan(du) || isnan(dv)) {
^
src/math/src/poly.findroots.c:287:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
: recipe for target 'src/math/src/polyc.o' failed
Thanks for the help
Trying to compile Liquid for modern PPC targets with the NXP SDK:
user@host:~/dev/liquid-dsp$ make
powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e6500 --sysroot=/opt/fsl-qoriq/2.0/sysroots/ppce6500-fsl-linux -O2 -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -O2 -pipe -g -feliminate-unused-debug-types -fno-common -faltivec -c -o src/libliquid.o src/libliquid.c
powerpc-fsl-linux-gcc: error: unrecognized command line option '-faltivec'
<builtin>: recipe for target 'src/libliquid.o' failed
make: *** [src/libliquid.o] Error 1
Perhaps -faltivec
is a Mac thing. It appears that GCC uses -maltivec -mabi=altivec
. I know autoconfigure has the ability to discover the correct flags, because FFTW does so. I changed the makefile and was able to continue with the compilation. However, it failed at the dotprod module thus:
powerpc-fsl-linux-gcc -m32 -mhard-float -mcpu=e6500 --sysroot=/opt/fsl-qoriq/2.0/sysroots/ppce6500-fsl-linux -O2 -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -O2 -pipe -g -feliminate-unused-debug-types -fno-common -maltivec -mabi=altivec -c -o src/dotprod/src/dotprod_rrrf.av.o src/dotprod/src/dotprod_rrrf.av.c
src/dotprod/src/dotprod_rrrf.av.c: In function 'dotprod_rrrf_execute':
src/dotprod/src/dotprod_rrrf.av.c:176:5: error: can't convert between vector values of different size
s0 = s1 = s2 = s3 = (vector float)(0);
^
src/dotprod/src/dotprod_rrrf.av.c:178:9: warning: implicit declaration of function 'vec_madd' [-Wimplicit-function-declaration]
s0 = vec_madd(ar[nblocks-1],d[nblocks-1],s0);
^
src/dotprod/src/dotprod_rrrf.av.c:178:9: error: AltiVec argument passed to unprototyped function
src/dotprod/src/dotprod_rrrf.av.c:179:9: error: AltiVec argument passed to unprototyped function
s1 = vec_madd(ar[nblocks-2],d[nblocks-2],s1);
^
src/dotprod/src/dotprod_rrrf.av.c:180:9: error: AltiVec argument passed to unprototyped function
s2 = vec_madd(ar[nblocks-3],d[nblocks-3],s2);
^
src/dotprod/src/dotprod_rrrf.av.c:181:9: error: AltiVec argument passed to unprototyped function
s3 = vec_madd(ar[nblocks-4],d[nblocks-4],s3);
^
src/dotprod/src/dotprod_rrrf.av.c:186:5: warning: implicit declaration of function 'vec_add' [-Wimplicit-function-declaration]
s0 = vec_add(s0,s1); // s0 = s0+s1
^
src/dotprod/src/dotprod_rrrf.av.c:186:5: error: AltiVec argument passed to unprototyped function
src/dotprod/src/dotprod_rrrf.av.c:187:5: error: AltiVec argument passed to unprototyped function
s2 = vec_add(s2,s3); // s2 = s2+s3
^
src/dotprod/src/dotprod_rrrf.av.c:188:5: error: AltiVec argument passed to unprototyped function
s0 = vec_add(s0,s2); // s0 = s0+s2
^
src/dotprod/src/dotprod_rrrf.av.c:192:9: error: AltiVec argument passed to unprototyped function
s0 = vec_madd(ar[nblocks],d[nblocks],s0);
^
src/dotprod/src/dotprod_rrrf.av.c:197:5: error: can't convert between vector values of different size
s.v = vec_add(s0,(vector float)(0));
^
src/dotprod/src/dotprod_rrrf.av.c:197:5: error: AltiVec argument passed to unprototyped function
<builtin>: recipe for target 'src/dotprod/src/dotprod_rrrf.av.o' failed
make: *** [src/dotprod/src/dotprod_rrrf.av.o] Error 1
This code doesn't even have #include "altivec.h"
. Not sure how that was expected to work...
Anyway I added that but a few of the errors remain.
I am currently working on fixing the code, I will offer a pull request if I get it working.
One more question:
Why is LIQUID_IIRFILT_USE_DOTPROD
defined as 0
in iirfilt? If I can use SIMD acceleration for my filters, I'd like to do that.
thanks.
With gcc 5.3.0, I get:
In file included from src/math/src/polyc.c:43:0:
src/math/src/poly.findroots.c: In function ‘polyc_findroots_bairstow_recursion’:
src/math/src/poly.findroots.c:305:9: error: non-floating-point argument in call to function ‘__builtin_isnan’
if (isnan(du) || isnan(dv)) {
^
isnan doesn't work for T == double complex
(works fine in clang though)
This applies to current master (f6a33a6)
Channelizer is working perfectly for my purposes so far, but it would be helpful (if it improves CPU usage) to be able to toggle unused channels. Often what I want is in just one or two or may span two (reconstruct) and it seems wasteful if the unused channel data is still consuming cycles.
Thanks, Cheers!
It would be great if you could add support for double precision.
Thank you
Regard
Linus
Hi,
Since b3ed2ff crosscompiling using OpenEmbedded fails.
| mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float -march=mips32 --sysroot=.... -Os -pipe -g -feliminate-unused-debug-types -I . -I include -Wall -fPIC -msse3 -Os -pipe -g -feliminate-unused-debug-types -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c
| mipsel-oe-linux-gcc: error: unrecognized command line option '-msse3'
Is it possible to add a proper test in order to enable sse3 instead of hardcoding to CFLAGS?
E.g. http://www.gnu.org/software/autoconf-archive/ax_ext.html
I am trying this file:
http://liquidsdr.org/blog/raspberry-pi3-benchmarks/benchmark_threaded.c
cpchung:temp$ gcc -Wall -O2 -pthread -lm -lc -lliquid -o benchmark_threaded benchmark_threaded.c
/tmp/ccLGDpmH.o: In function process_worker': benchmark_threaded.c:(.text+0x2d): undefined reference to
firfilt_crcf_execute_block'
/tmp/ccLGDpmH.o: In function process_create': benchmark_threaded.c:(.text+0x25d): undefined reference to
firfilt_crcf_create_kaiser'
benchmark_threaded.c:(.text+0x271): undefined reference to firfilt_crcf_set_scale' benchmark_threaded.c:(.text+0x29b): undefined reference to
randnf'
benchmark_threaded.c:(.text+0x2b5): undefined reference to randnf' /tmp/ccLGDpmH.o: In function
process_destroy':
benchmark_threaded.c:(.text+0x305): undefined reference to firfilt_crcf_destroy' /tmp/ccLGDpmH.o: In function
benchmark':
benchmark_threaded.c:(.text+0x453): undefined reference to roundf' /tmp/ccLGDpmH.o: In function
main':
benchmark_threaded.c:(.text.startup+0x332): undefined reference to `ceilf'
collect2: error: ld returned 1 exit status
cpchung:temp$ locate liquid.h
/home/cpchung/liquid-dsp/include/liquid.h
/usr/local/include/liquid/liquid.h
Trying to configure and build liquid-dsp. When I run configure I get
./configure: line 4571: syntax error near unexpected token no,,' ./configure: line 4571:
AX_GCC_ARCHFLAG(no,,)'
As I am relatively inexperienced with this script I cant figure out what the syntax should be.
I an using Ubuntu of x86 64 bit
It seems that fskmod
and similar modules (cpfsk*
) are missing from the documentation.
I was wondering if this was a mishap, or if the documentation is still under development?
I'm running through the build of CubicSDR from CJ Cliffe's project https://github.com/cjcliffe/CubicSDR/wiki/Build-Linux. I'm having a problem building liquid-dsp by pulling from
git clone https://github.com/jgaeddert/liquid-dsp
liquid-dsp$ cd liquid-dsp
liquid-dsp$ ./bootstrap.sh
liquid-dsp$ ./configure --enable-fftoverride
liquid-dsp$ make -j4
The make output is posted below. I have two laptops sitting side by side with the same error in the same location of the build. Both are i386 machines with Debian. One is running Jessie and has an AMD dual core and the other is running Sid and has an Intel dual core.
I can pull the source code http://liquidsdr.org/downloads/liquid-dsp-1.2.0.tar.gz and compile and install on both machines with no issues. However, this does not seem to bode well for CubicSDR, CubicSDR fails to build and complains about liquid-dsp. cjcliffe/CubicSDR#393
Any help would be appreciated. And thanks for all the time and effort you've put into the project.
Here's the breakpoint
$ make -j4 gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/libliquid.o src/libliquid.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/agc/src/agc_crcf.o src/agc/src/agc_crcf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/agc/src/agc_rrrf.o src/agc/src/agc_rrrf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/audio/src/cvsd.o src/audio/src/cvsd.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/buffer/src/bufferf.o src/buffer/src/bufferf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/buffer/src/buffercf.o src/buffer/src/buffercf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/channel/src/channel_cccf.o src/channel/src/channel_cccf.c gcc -I . -I include -Wall -fPIC -g -O2 -march=pentium-m -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’: /usr/lib/gcc/i686-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: /usr/lib/gcc/i686-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ <builtin>: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1 make: *** Waiting for unfinished jobs....
This might be related to other things that are already reported and being worked on, but I wasn't really sure so I opened a new bug here.
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/equalization/s
rc/equalizer_rrrf.o src/equalization/src/equalizer_rrrf.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/crc.o
src/fec/src/crc.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/fec.o
src/fec/src/fec.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/fec_co
nv.o src/fec/src/fec_conv.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/fec_co
nv_poly.o src/fec/src/fec_conv_poly.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/fec_co
nv_pmatrix.o src/fec/src/fec_conv_pmatrix.c
x86_64-pc-linux-gnu-gcc -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -I . -I include -Wall -fPIC -Os -mtune=nocona -pipe -ggdb -frecord-gcc-switches -c -o src/fec/src/fec_conv_punctured.o src/fec/src/fec_conv_punctured.c
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
src/dotprod/src/dotprod_rrrf.mmx.c: In function ‘dotprod_rrrf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
_mm_hadd_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_rrrf.mmx.c:203:9: error: called from here
sum = _mm_hadd_ps(sum, z);
^
In file included from src/dotprod/src/dotprod_rrrf.mmx.c:50:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
_mm_hadd_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_rrrf.mmx.c:204:9: error: called from here
sum = _mm_hadd_ps(sum, z);
^
make: *** [<builtin>: src/dotprod/src/dotprod_rrrf.mmx.o] Error 1
make: *** Waiting for unfinished jobs....
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
make: *** [<builtin>: src/dotprod/src/dotprod_cccf.mmx.o] Error 1
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
src/dotprod/src/sumsq.mmx.c: In function ‘liquid_sumsqf’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
_mm_hadd_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/sumsq.mmx.c:85:9: error: called from here
sum = _mm_hadd_ps(sum, z);
^
In file included from src/dotprod/src/sumsq.mmx.c:49:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/include/pmmintrin.h:56:1: error: inlining failed in call to always_inline ‘_mm_hadd_ps’: target specific option mismatch
_mm_hadd_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/sumsq.mmx.c:86:9: error: called from here
sum = _mm_hadd_ps(sum, z);
^
make: *** [<builtin>: src/dotprod/src/sumsq.mmx.o] Error 1
I am current working the latest build from the master branch.
I recently discovered that a segfault occurs when I call symsync_crcf_destroy from my class destructor. The cause of the segfault is an attempt to free heap memory that was never allocated. I did not investigate the issue in-depth, but briefly looking at the source it looks like it has to do with how the symsync filter module is initializing its IIR filter.
I see the docs (and the bench output) mention libfec, but I can't for the life of me find libfec — well, more precisely, I found a couple things that might be libfec.
I forked one from Google code, and the more likely one seems to be from ka9q.net … but it won't compile on my modern computer. Some of the preprocessor directives comment out too much code, which is fixable, but other linking issues come up too.
Is that the right one? I can probably fix it or is it the Google code one? Asking for a quick doc fix here, sortof along the lines of changing “libfec” to “libfec by so-and-so.”
Hi, I have a problem with framesync64_print(fs) function while compiling 3rd tutorial. It isn't printing details and properties. I am using eclipse environment but after compiling project under console and run it, it throws "Segmentation fault" message. I could not find the issue of this also I do not have an opportunity to check this program on other machine. Waiting for help.
-Martin
I'm a Linux dev for a university CubeSat team, and we hope to use your frontend to apply Reed-Solomon encoding to our radio transmissions for FEC.
How can we detect the number of bit errors if we don't have the original message present on the receiving end? All of the example programs simply use the original message to do this, but I thought Reed-Solomon has some sort of built in "parity checking" that you can use to gauge if you're past the number of correctable errors.
We're compiling libfec for the MitySOM335x and are seeing the following errors:
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... no
checking fec.h usability... no
checking fec.h presence... no
checking for fec.h... no
checking fftw3.h usability... no
checking fftw3.h presence... no
checking for fftw3.h... no
checking for fftwf_plan_dft_1d in -lfftw3f... no
configure: WARNING: fftw3 library useful but not required
checking for create_viterbi27 in -lfec... no
configure: WARNING: fec library useful but not required
Related to not finding malloc:
src/audio/src/cvsd.c: In function 'cvsd_create':
src/audio/src/cvsd.c:74:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_golay2412.c: In function 'fec_golay2412_create':
src/fec/src/fec_golay2412.c:240:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming74.c: In function 'fec_hamming74_create':
src/fec/src/fec_hamming74.c:60:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming84.c: In function 'fec_hamming84_create':
src/fec/src/fec_hamming84.c:76:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_hamming128.c: In function 'fec_hamming128_create':
src/fec/src/fec_hamming128.c:146:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_pass.c: In function 'fec_pass_create':
src/fec/src/fec_pass.c:34:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_rep3.c: In function 'fec_rep3_create':
src/fec/src/fec_rep3.c:35:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_rep5.c: In function 'fec_rep5_create':
src/fec/src/fec_rep5.c:35:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded2216.c: In function 'fec_secded2216_create':
src/fec/src/fec_secded2216.c:200:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded3932.c: In function 'fec_secded3932_create':
src/fec/src/fec_secded3932.c:216:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/fec_secded7264.c: In function 'fec_secded7264_create':
src/fec/src/fec_secded7264.c:219:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/interleaver.c: In function 'interleaver_create':
src/fec/src/interleaver.c:81:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/packetizer.c: In function 'packetizer_create':
src/fec/src/packetizer.c:98:5: warning: implicit declaration of function 'rpl_malloc'
src/fec/src/packetizer.c: In function 'packetizer_realloc_buffers':
src/fec/src/packetizer.c:419:5: warning: implicit declaration of function 'rpl_realloc'
src/filter/src/firdespm.c: In function 'firdespm_create':
src/filter/src/firdespm.c:249:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketgen.c: In function 'bpacketgen_create':
src/framing/src/bpacketgen.c:85:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketgen.c: In function 'bpacketgen_recreate':
src/framing/src/bpacketgen.c:160:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/bpacketsync.c: In function 'bpacketsync_create':
src/framing/src/bpacketsync.c:103:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/bpacketsync.c: In function 'bpacketsync_reconfig':
src/framing/src/bpacketsync.c:449:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/detector_cccf.c: In function 'detector_cccf_create':
src/framing/src/detector_cccf.c:124:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/framegen64.c: In function 'framegen64_create':
src/framing/src/framegen64.c:53:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/framesync64.c: In function 'framesync64_create':
src/framing/src/framesync64.c:125:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframegen.c: In function 'flexframegen_create':
src/framing/src/flexframegen.c:104:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframegen.c: In function 'flexframegen_reconfigure':
src/framing/src/flexframegen.c:390:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/flexframesync.c: In function 'flexframesync_create':
src/framing/src/flexframesync.c:147:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/flexframesync.c: In function 'flexframesync_decode_header':
src/framing/src/flexframesync.c:632:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/gmskframegen.c: In function 'gmskframegen_create':
src/framing/src/gmskframegen.c:92:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/gmskframegen.c: In function 'gmskframegen_assemble':
src/framing/src/gmskframegen.c:241:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/gmskframesync.c: In function 'gmskframesync_create':
src/framing/src/gmskframesync.c:160:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/gmskframesync.c: In function 'gmskframesync_decode_header':
src/framing/src/gmskframesync.c:832:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/ofdmflexframegen.c: In function 'ofdmflexframegen_create':
src/framing/src/ofdmflexframegen.c:155:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/ofdmflexframegen.c: In function 'ofdmflexframegen_reconfigure':
src/framing/src/ofdmflexframegen.c:441:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/ofdmflexframesync.c: In function 'ofdmflexframesync_create':
src/framing/src/ofdmflexframesync.c:141:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/ofdmflexframesync.c: In function 'ofdmflexframesync_decode_header':
src/framing/src/ofdmflexframesync.c:571:9: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/qdetector_cccf.c: In function 'qdetector_cccf_create':
src/framing/src/qdetector_cccf.c:96:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpacketmodem.c: In function 'qpacketmodem_create':
src/framing/src/qpacketmodem.c:55:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpacketmodem.c: In function 'qpacketmodem_configure':
src/framing/src/qpacketmodem.c:148:5: warning: implicit declaration of function 'rpl_realloc'
src/framing/src/qpilotgen.c: In function 'qpilotgen_create':
src/framing/src/qpilotgen.c:63:5: warning: implicit declaration of function 'rpl_malloc'
src/framing/src/qpilotsync.c: In function 'qpilotsync_create':
src/framing/src/qpilotsync.c:74:5: warning: implicit declaration of function 'rpl_malloc'
In file included from src/matrix/src/smatrixb.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixb_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixb_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
In file included from src/matrix/src/smatrixf.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixf_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixf_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
In file included from src/matrix/src/smatrixi.c:48:0:
src/matrix/src/smatrix.c: In function 'smatrixi_create':
src/matrix/src/smatrix.c:71:5: warning: implicit declaration of function 'rpl_malloc'
src/matrix/src/smatrix.c: In function 'smatrixi_insert':
src/matrix/src/smatrix.c:325:5: warning: implicit declaration of function 'rpl_realloc'
src/modem/src/ampmodem.c: In function 'ampmodem_create':
src/modem/src/ampmodem.c:78:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/cpfskdem.c: In function 'cpfskdem_create':
src/modem/src/cpfskdem.c:156:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/cpfskmod.c: In function 'cpfskmod_create':
src/modem/src/cpfskmod.c:100:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/fskdem.c: In function 'fskdem_create':
src/modem/src/fskdem.c:81:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/fskmod.c: In function 'fskmod_create':
src/modem/src/fskmod.c:70:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/gmskdem.c: In function 'gmskdem_create':
src/modem/src/gmskdem.c:88:5: warning: implicit declaration of function 'rpl_malloc'
src/modem/src/gmskmod.c: In function 'gmskmod_create':
src/modem/src/gmskmod.c:67:5: warning: implicit declaration of function 'rpl_malloc'
src/multichannel/src/ofdmframegen.c: In function 'ofdmframegen_create':
src/multichannel/src/ofdmframegen.c:105:5: warning: implicit declaration of function 'rpl_malloc'
src/multichannel/src/ofdmframesync.c: In function 'ofdmframesync_create':
src/multichannel/src/ofdmframesync.c:147:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/chromosome.c: In function 'chromosome_create':
src/optim/src/chromosome.c:43:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/gasearch.c: In function 'gasearch_create_advanced':
src/optim/src/gasearch.c:72:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/gasearch.c: In function 'gasearch_set_population_size':
src/optim/src/gasearch.c:181:5: warning: implicit declaration of function 'rpl_realloc'
src/optim/src/gradsearch.c: In function 'gradsearch_create':
src/optim/src/gradsearch.c:59:5: warning: implicit declaration of function 'rpl_malloc'
src/optim/src/qnsearch.c: In function 'qnsearch_create':
src/optim/src/qnsearch.c:37:5: warning: implicit declaration of function 'rpl_malloc'
src/sequence/src/bsequence.c: In function 'bsequence_create':
src/sequence/src/bsequence.c:51:5: warning: implicit declaration of function 'rpl_malloc'
src/sequence/src/msequence.c: In function 'msequence_create':
src/sequence/src/msequence.c:77:5: warning: implicit declaration of function 'rpl_malloc'
src/utility/src/shift_array.c: In function 'liquid_lcircshift':
src/utility/src/shift_array.c:101:5: warning: implicit declaration of function 'rpl_malloc'
arm-arago-linux-gnueabi-ar: creating libliquid.a
Everything compiles and works fine natively, so it's possible that our CMake setup is not passing options appropriately to autoconf. Here's what we're using to pull in your project:
ExternalProject_Add(${LIQUID_NAME}
DEPENDS fec
PREFIX ${LIQUID_NAME}
GIT_REPOSITORY https://github.com/jgaeddert/liquid-dsp.git
INSTALL_COMMAND ${CDH_SUDO} ${MAKE} install # ${CDH_INSTALL_CMD}
INSTALL_DIR ${CDH_INSTALL_DIR}
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> ${CDH_CMAKE_ARGS}
UPDATE_COMMAND ${LIQUID_LIB_BUILD_DIR}/bootstrap.sh
CONFIGURE_COMMAND ${LIQUID_LIB_BUILD_DIR}/configure --prefix=<INSTALL_DIR> ${CDH_AUTOCONF_HOST} ${CDH_AUTOCONF_BUILD}
BUILD_COMMAND ${MAKE}
## CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${LIQUID_LIB_PREFIX_DIR}
## CMAKE_GENERATOR ${CMAKE_GENERATOR}
BUILD_IN_SOURCE 1
## INSTALL_COMMAND ""
# UPDATE_COMMAND ""
)
The important bit is the ${CDH_AUTOCONF_HOST} and ${CDH_AUTOCONF_BUILD} variables, which have respective values of --host=arm-arago-linux-gnueabi
and --build=i386-pc-linux-gnu
I think this has something to do with the include directories used by cmake not being properly passed into autoconf, though that's just a guess. Have you all successfully built this library for ARM targets before?
I was wondering if this is a soft limit just for sanity or if it's possible to uncap it.. Or should I really be doing something different like another fixed resampler stage before it?
It happens now when my input bandwidth is 3.2M and I'm attempting to resample to ~1.5khz or lower. It isn't much of a problem at the moment since the usable bandwidth for devices is below the 10 stage limit -- but I'm about to add support for devices that may go as high as 8M - 10M input bandwidth and it will become a much bigger issue.
Iam trying to install on debian jessie armhf cant get pass "make comand"
ERROR:
root@/liquid-dsp# make
gcc -I . -I include -Wall -fPIC -g -O2 -ffast-math -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon -c -o src/libliquid.o src/libliquid.c
In file included from /usr/include/features.h:398:0,
from /usr/include/complex.h:25,
from include/liquid.h:78,
from src/libliquid.c:27:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory
^
compilation terminated.
: recipe for target 'src/libliquid.o' failed
make: *** [src/libliquid.o] Error 1
At my last job we were in awe of liquid DSP's completeness and documentation, but we were not legally/contractually allowed to use GPL code. Would you be open to release it under a more liberal license?
I also ask because I'm working on some DSP and communications code for the Julia language, which can directly call c libraries. I'd love to link to Liquid, but the Julia community prefers the MIT license, and is actively trying to migrate away from all its GPL dependencies.
I'm sorry if this is an offensive request, and will completely understand if you prefer sticking to GPL.
There is a small issue with the following code from liquid.h when using it with Clang and libc++ (http://libcxx.llvm.org):
#if LIQUID_USE_COMPLEX_H==1
# include <complex.h>
# define LIQUID_DEFINE_COMPLEX(R,C) typedef R _Complex C
#elif defined _GLIBCXX_COMPLEX
# define LIQUID_DEFINE_COMPLEX(R,C) typedef std::complex<R> C
#else
# define LIQUID_DEFINE_COMPLEX(R,C) typedef struct {R real; R imag;} C;
#endif
//# define LIQUID_DEFINE_COMPLEX(R,C) typedef R C[2]
_GLIBCXX_COMPLEX
is not defined under libc++, which instead defines _LIBCPP_COMPLEX
. The following small change is therefore suggested.
#if LIQUID_USE_COMPLEX_H==1
# include <complex.h>
# define LIQUID_DEFINE_COMPLEX(R,C) typedef R _Complex C
#elif defined _GLIBCXX_COMPLEX || defined _LIBCPP_COMPLEX
# define LIQUID_DEFINE_COMPLEX(R,C) typedef std::complex<R> C
#else
# define LIQUID_DEFINE_COMPLEX(R,C) typedef struct {R real; R imag;} C;
#endif
//# define LIQUID_DEFINE_COMPLEX(R,C) typedef R C[2]
Is it in a separate repo?
I was following the Installation guide, but when I executed the make I had some issues.
Can anyone help me?
liquid-dsp$ make
gcc -I . -I include -Wall -fPIC -g -O2 -c -o src/dotprod/src/dotprod_cccf.mmx.o src/dotprod/src/dotprod_cccf.mmx.c
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch
_mm_addsub_ps (__m128 __X, __m128 __Y)
^
src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here
s = _mm_addsub_ps( ci, cq );
^
: recipe for target 'src/dotprod/src/dotprod_cccf.mmx.o' failed
make: *** [src/dotprod/src/dotprod_cccf.mmx.o] Error 1
Just in case you didn't know, the site's been down for a few days now
I noticed that the number of errors detected in the example programs all were in reference to the original data. Where we don't have the original data, it would be really nice to have "derrors" available either through direct access to the struct, or through some sort of helper function on the fec_s struct.
Thoughts?
Its somewhat expected behaviour to build and install with the command make install
but this fails with the current lease version of liquid-dsp. This is because there is no dependency rule for the install command. I suggest to add all
as dependency for the install rule to enable this behaviour.
It would be nice if liquid-dsp would be able to modulate/demodulate FSK signals.
What do you think about it?
Building the release tarball of version 1.2.0 of liquid-dsp fails when using LLVM/Clang on Mac OS X (documented in troubleshooting section of manual/website). Currently the suggested fix is to use GCC instead (related issue #48), but this is not favored by Homebrew's maintainers (see isse Homebrew/homebrew-core#2664). Therefore I tried to build the latest release with LLVM/Clang and the only issues seems to be the configure script checks for malloc
, realloc
, free
, memset
, memmove
in libc and sinf
, cosf
, expf
, cargf
, cexpf
, crealf
, cimagf
, sqrtf
in libm:
checking for malloc, realloc, free, memset, memmove in -lc... no
configure: error: Need standard c library!
and
checking for sinf, cosf, expf, cargf, cexpf, crealf, cimagf, sqrtf in -lm... no
configure: error: Need standard (complex) math library!
Possible fixes:
The patch could simply replace lines 160 to 166 in configure.ac
with the corresponding lines in the master
branch.
If this patch is applied building with LLVM/Clang succeeds and make check
passes (PASSED ALL 42373 CHECKS
with WARNINGS : 34
).
Following the described procedure I get the following error running Configure and would appreciate any assistance. The target is a Raspberry Pi 2.
Thanks, Bob W9RAN
./configure: line 4571: syntax error near unexpected token no,,' ./configure: line 4571:
AX_GCC_ARCHFLAG(no,,)'
root@raspberrypi:~/Downloads/liquid-dsp# make
make: *** No targets specified and no makefile found. Stop.
I just noticed an odd result when performing the same filtering operation through firdecim and firpfb.
I wanted to be able to adjust the output phase using a timing estimate from my signal, so first I tested the output of firpfb with a fixed phase (0).
From my understanding the output signals should be the same (as a polyphase filter is just a more efficient implementation of FIR filtering + decimation/interpolation). Then I noticed that the current implementation just subsamples the filter coefficients to form M filters and each output sample only uses 1 of them.
Am i missing something? Is this behavior unintended? If so, I can help here.
Keep up the good work!
I'm using an embedded application. I don't want all sorts of junk on the screen. Can anyone explain why I get so much junk printed to the screen when specifying anything other than -n 16 in the example code? Notice I'm using the -q flag. I've played with the code, and this is definitely coming from the fft_execute() function.
user@host:~/dev/liquid-dsp-1.3.0/examples$ ./fft_example -q -n 10
fft plan [forward], n=10, Cooley-Tukey
10, Cooley-Tukey mixed radix, Q=2, P=5
2, DFT
5, DFT
computing 5 DFTs of size 2
i= 0/ 5
45.000000 -45.000000
-5.000000 5.000000
i= 1/ 5
10.388418 20.388418
-6.624599 3.375402
i= 2/ 5
1.881910 11.881909
-8.632713 1.367286
i= 3/ 5
-1.367286 8.632712
-11.881909 -1.881909
i= 4/ 5
-3.375401 6.624599
-20.388420 -10.388417
computing 5 DFTs of size 2
i= 0/ 5
0.000004 0.000000
50.000004 -50.000000
i= 1/ 5
9.999996 -9.999998
60.000004 -60.000008
i= 2/ 5
19.999996 -19.999996
70.000000 -70.000000
i= 3/ 5
30.000000 -30.000000
80.000000 -80.000000
i= 4/ 5
39.999996 -40.000000
90.000000 -90.000000
rmse = 4.6398e-07
done.
I'm attempting to use the multi stage resampler to resample an input waveform to an arbitrary rate. Unfortunately, I'm not getting the results I would expect. I've looked at the example and am trying to adapt it to my particular use case...
My setup is the following:
Input rate: 37777.0
Output rate: 5540.0
R ~ 0.14665007808984304
As = 120 (i know this is excessive, the problem is present at lower (80) attenuation as well)
My test waveform is a complex tone, amplitude 1, with frequency 55.40 Hz, it has 6819 samples. This should produce ten cycles at the end sample rate and 1000 samples.
(6819*5540/37777) =1000.0068..
For the most part, this is what happens. However, the start and endpoints don't look as "nice" as I had hoped. for example, at different "R"s I may get an overshoot of as much as 0.1. Clearly, some is to be expected, I just wanted to verify that this is correct and that I am not doing something wrong.
My code performs three executes, at first, I only push filter delay worth of samples into the resampler. Then I push the remaining input data. This way, I can throw away the useless samples. Lastly I push a set of zeroes (size of delay) into the filter to get out the remaining samples. Then I truncate the output buffer and I'm all done. At this point I have the delay compensated output. Here is the execute portion of the code for reference.
size_t output_size = std::floor(input_data.size() * _r);
//allocate some buffer space, it will be truncated later, lots of extra space here
_output_data->resize(output_size + 2 * _delay + std::ceil(_r));
unsigned int ny = 0;
size_t written = 0;
float frac_delay = msresamp_crcf_get_delay(_resamp);
int delay = std::ceil(frac_delay);
std::vector<std::complex<float> > shifter;
shifter.resize(delay, std::complex<float>(0, 0));
//push the first delay samples through the resampler, we will overwrite the results
msresamp_crcf_execute(_resamp, input_data.data(), delay, _output_data->data(), &ny);
//now push the remaining samples through the filter, start at index 0 of the output data
msresamp_crcf_execute(_resamp, &input_data.at(delay), input_data.size() - delay, _output_data->data(), &ny);
//lastly, push an array of zeroes with delay size through the filter to get the rest of the samples
msresamp_crcf_execute(_resamp, shifter.data(), shifter.size(), &_output_data->at(ny), &ny);
//truncate our output data to only contain the delay compensated result
_output_data->resize(output_size);
Link to some plots:
http://imgur.com/a/k3gwL
Notice that the first sample of the output data seems incorrect. Should it not be 1?
My question is quite simple, is this procedure functionally correct? If not, where did I slip up? Thank you for any insight.
Also there is a typo in the documentation: for the multistage resampler interface documentation:
http://liquidsdr.org/doc/msresamp/
The call is: msresamp_crcf_execute(q,*x,nx,*y,*ny), not msresamp_crcf_filter_execute(q,*x,nx,*y,*ny)
cheers,
dominik
Hi,
I tried to cross-compile liquid-dsp library using PTXDIST.
Everything works as expected until the build process want's to execute reverse_byte_gentab.
The executeable is build for the target architecture, but tries to run on my host architecture.
So the reverse_byte_gentab executeable need so be compiled by the host compiler.
I'm not familar enough with autotools so i don't know how i may change this behaviour.
Greetings,
Florian
I would like to use the library under windows on an STM32F7 (GCC_Eclipse).
any help??
src/dotprod/src/dotprod_cccf.mmx.c: In function ‘dotprod_cccf_execute_mmx’: src/dotprod/src/dotprod_cccf.mmx.c:225:12: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi] __m128 sum = _mm_setzero_ps(); // load zeros into sum register ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:115:1: error: inlining failed in call to always_inline ‘_mm_setzero_ps’: target specific option mismatch _mm_setzero_ps (void) ^ src/dotprod/src/dotprod_cccf.mmx.c:225:12: error: called from here __m128 sum = _mm_setzero_ps(); // load zeros into sum register ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:929:1: error: inlining failed in call to always_inline ‘_mm_loadu_ps’: target specific option mismatch _mm_loadu_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:240:11: error: called from here v = _mm_loadu_ps(&x[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:922:1: error: inlining failed in call to always_inline ‘_mm_load_ps’: target specific option mismatch _mm_load_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:243:12: error: called from here hi = _mm_load_ps(&_q->hi[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:922:1: error: inlining failed in call to always_inline ‘_mm_load_ps’: target specific option mismatch _mm_load_ps (float const *__P) ^ src/dotprod/src/dotprod_cccf.mmx.c:244:12: error: called from here hq = _mm_load_ps(&_q->hq[i]); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:193:1: error: inlining failed in call to always_inline ‘_mm_mul_ps’: target specific option mismatch _mm_mul_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:247:12: error: called from here ci = _mm_mul_ps(v, hi); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:193:1: error: inlining failed in call to always_inline ‘_mm_mul_ps’: target specific option mismatch _mm_mul_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:248:12: error: called from here cq = _mm_mul_ps(v, hq); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:741:1: error: inlining failed in call to always_inline ‘_mm_shuffle_ps’: target specific option mismatch _mm_shuffle_ps (__m128 __A, __m128 __B, int const __mask) ^ src/dotprod/src/dotprod_cccf.mmx.c:251:12: error: called from here cq = _mm_shuffle_ps( cq, cq, _MM_SHUFFLE(2,3,0,1) ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:49:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/pmmintrin.h:50:1: error: inlining failed in call to always_inline ‘_mm_addsub_ps’: target specific option mismatch _mm_addsub_ps (__m128 __X, __m128 __Y) ^ src/dotprod/src/dotprod_cccf.mmx.c:255:11: error: called from here s = _mm_addsub_ps( ci, cq ); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:181:1: error: inlining failed in call to always_inline ‘_mm_add_ps’: target specific option mismatch _mm_add_ps (__m128 __A, __m128 __B) ^ src/dotprod/src/dotprod_cccf.mmx.c:258:13: error: called from here sum = _mm_add_ps(sum, s); ^ In file included from src/dotprod/src/dotprod_cccf.mmx.c:41:0: /usr/lib/gcc/i586-linux-gnu/4.9/include/xmmintrin.h:971:1: error: inlining failed in call to always_inline ‘_mm_store_ps’: target specific option mismatch _mm_store_ps (float *__P, __m128 __A) ^ src/dotprod/src/dotprod_cccf.mmx.c:276:5: error: called from here _mm_store_ps(w, sum);
Exact output was:
checking whether mmx is supported... ./configure: line 4843: 0xunknown: value too great for base (error token is "0xunknown")
I'm running this on x86_64 Arch Linux. No other previous errors/warnings were given. I've gone through this process on Ubuntu and Fedora with success, but I haven't run into this problem before. Any clues as to what's going on and what to do? Thanks in advance!
Just to clarify: this error results in no Makefile being generated, so running make returns with make: *** No targets specified and no makefile found. Stop.
in http://liquidsdr.org/doc/windowing/ kaiser is defined as kaiser(n,N,dt,beta), but in liquid.h it is defined as:
float kaiser(unsigned int _n,
unsigned int _N,
float _beta,
float _dt);
The dt and beta parameters are reversed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.