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]

ha7ilm/csdr#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