Debian Buster on OrangePi

[loewal]

Since I installed Debian Buster on my OrangePi PC-2, it takes about hals a minute to display a running waterfall. Changing all kinds of parameters give no result. Even changing buffersize from 6 to 1 still shows an audiobuffer of 2.1 seconds. What is happening? After one minute it runs quite well, but that slow startup.....?

[bclswl0827]

https://github.com/simonyiszk/csdr/issues/11 Orange pi pc-2 uses Cortex-A53, you need to manually modify the Makefile when compiling csdr…

[loewal]

And how....? Thnx!

[loewal]

PARAMS_NEON = -O3 -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fomit-frame-pointer -funroll-loops -Wformat=0

PARAMS_NEON = -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS

tnx Jan Szumiec for the Raspberry Pi support

PARAMS_RASPI = -mfloat-abi=hard -mcpu=arm1176jzf-s -mfpu=vfp -funsafe-math-optimizations -Wformat=0

PARAMS_RASPI = -mcpu=cortex-a53 -mtune=cortex-a53 -funsafe-math-optimizations -Wformat=0

[loewal]

it compiles, but the result....the same

[bclswl0827]

PARAMS_NEON = -O3 -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fomit-frame-pointer -funroll-loops -Wformat=0

PARAMS_NEON = -mfloat-abi=hard -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mvectorize-with-neon-quad -funsafe-math-optimizations -Wformat=0 -DNEON_OPTS

tnx Jan Szumiec for the Raspberry Pi support

PARAMS_RASPI = -mfloat-abi=hard -mcpu=arm1176jzf-s -mfpu=vfp -funsafe-math-optimizations -Wformat=0

PARAMS_RASPI = -mcpu=cortex-a53 -mtune=cortex-a53 -funsafe-math-optimizations -Wformat=0

Keep PARAMS_RASPI unchanged, It should like this:

PARAMS_NEON = -O3 -mcpu=cortex-a53 -march=armv8-a+crc+crypto -fomit-frame-pointer -funroll-loops -Wformat=0
#tnx Jan Szumiec for the Raspberry Pi support
PARAMS_RASPI = -mfloat-abi=hard -mcpu=arm1176jzf-s -mfpu=vfp -funsafe-math-optimizations -Wformat=0

[loewal]

Still the same: Part of the output... libcsdr.c:123:5: note: LOOP VECTORIZED normalize_fir_f: normalize pass 2 libcsdr.c:121:5: note: LOOP VECTORIZED normalize_fir_f: normalize pass 1 libcsdr.c:136:5: note: not vectorized: loop contains function calls or data references that cannot be analyzed firdes_lowpass_f: calculate taps libcsdr.c:156:5: note: not vectorized: multiple nested loops. firdes_bandpass_c libcsdr.c:162:14: note: not vectorized: number of iterations cannot be computed. firdes_bandpass_c libcsdr.c:161:14: note: not vectorized: number of iterations cannot be computed. firdes_bandpass_c libcsdr.c:193:5: note: not vectorized: multiple nested loops. shift_math_cc libcsdr.c:204:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase libcsdr.c:203:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase libcsdr.c:217:5: note: not vectorized: relevant stmt not supported: _34 = __builtin_sinf (_30); libcsdr.c:217:5: note: not vectorized: relevant stmt not supported: _34 = __builtin_sinf (_30); libcsdr.c:237:5: note: not vectorized: multiple nested loops. shift_math_cc libcsdr.c:262:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase libcsdr.c:261:14: note: not vectorized: number of iterations cannot be computed. shift_math_cc: normalize phase libcsdr.c:276:5: note: not vectorized: multiple nested loops.

It takes 35 seconds before the waterfall starts to move and another 5 for hearing sound. Soundbuffer around 2.2 seconds. Strange because i use a value of 1 (to test) in config_webrx.py.

More strange, because when running under Jessie last week I didn't need to change anything to compile....

[loewal]

Now running Buster

[bclswl0827]

Perhaps not the fault of csdr, do you mind pasting the OpenWebRX configure file here and let me have a look?

[loewal]

Changed it to .txt....... config_webrx.txt

[loewal]

This configuration is the same, except buffervalue, which was 6. Changed it to check if it made any difference. After 45 seconds it runs fine. OrangePi load is about 40%.

[loewal]

It runs on an Orange Pi pc2 and a Cubietruck 3. Both ran well last week under Jessie.

[bclswl0827]

This configuration is the same, except buffervalue, which was 6. Changed it to check if it made any difference. After 45 seconds it runs fine. OrangePi load is about 40%.

Try to decrease the value of fft_size & fft_voverlap_factor and see if there is any improvement.

fft_size = 4096
fft_voverlap_factor = 0.2

[loewal]

I am sorry, but I think you attack this problem the wrong way (sorry!). Only the startup is slow, after that its allright. I used the same settings last week under Jessie, so it is not logical to change them. I changed it, but startup still the same and audibuffer 2.1 secs.

[bclswl0827]

These are some general solutions... I'm sorry for leading you into a wrong way : ( It seems you're using SDRPlay, you can change the value of nmux_memory to 128 or higher, which can increase the size of the circular buffer used by nmux. Other than that, I can't remind a better way. I also use Debian Buster on Orange Pi Lite, RTL-SDR, up to now, everything goes well... Again, sorry to bring you so much trouble.

[loewal]

Installed OpenWebRX following the instructions of Andras Retzler (https://blog.sdr.hu/2015/06/30/quick-setup-openwebrx.html) on my new Raspberry Pi 4. Exactly the same slow start as the other two. Help anyone??

[ha7ilm]

Are you viewing the web interface on a browser on the (Orange)Pi itself, or on a different computer, like a laptop with a better CPU?

[loewal]

On my iMac. I installed it on 3 mini’s including Pi4. On Jessie it was fine. Buster? Sloooooow