Not building on Raspberry Pi OS (32-bit)

Question

Not building on Raspberry Pi OS (32-bit)

m-roberts opened this issue 3 years ago · comments

I ran sudo apt-get build-dep . to install build dependencies.

Then I ran make:

make[1]: Entering directory '/home/pi/vital'
make -C standalone/builds/linux CONFIG=Release SIMDFLAGS="-march=armv8-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard" GLFLAGS="-DOPENGL_ES=1" BUILD_DATE="2021 02 25 12 40"
make[2]: Entering directory '/home/pi/vital/standalone/builds/linux'
Compiling common.cpp
In file included from ../../../src/synthesis/framework/common.h:41,
                 from ../../../src/interface/editor_components/open_gl_component.h:19,
                 from ../../../src/interface/editor_components/open_gl_image_component.h:19,
                 from ../../../src/interface/editor_components/synth_button.h:21,
                 from ../../../src/interface/editor_sections/authentication_section.h:24,
                 from ../../../src/interface/editor_sections/full_interface.h:22,
                 from ../../../src/common/border_bounds_constrainer.cpp:18,
                 from ../../../src/unity_build/common.cpp:18:
../../../src/synthesis/framework/poly_values.h: In static member function ‘static vital::poly_float::simd_type vital::poly_float::div(vital::poly_float::simd_type, vital::poly_float::simd_type)’:
../../../src/synthesis/framework/poly_values.h:592:14: error: ‘vdivq_f32’ was not declared in this scope
       return vdivq_f32(one, two);
              ^~~~~~~~~
../../../src/synthesis/framework/poly_values.h:592:14: note: suggested alternative: ‘vzipq_f32’
       return vdivq_f32(one, two);
              ^~~~~~~~~
              vzipq_f32
In file included from ../../../src/unity_build/common.cpp:25:
../../../src/common/synth_gui_interface.cpp: In member function ‘void SynthGuiInterface::setGuiSize(float)’:
../../../src/common/synth_gui_interface.cpp:199:103: warning: ‘const juce::Displays::Display& juce::Displays::findDisplayForPoint(juce::Point<int>, bool) const’ is deprecated [-Wdeprecated-declarations]
   const Displays::Display& display = Desktop::getInstance().getDisplays().findDisplayForPoint(position);
                                                                                                       ^
In file included from ../../../third_party/JUCE/modules/juce_core/system/juce_StandardHeader.h:69,
                 from ../../../third_party/JUCE/modules/juce_core/juce_core.h:203,
                 from ../../../third_party/JUCE/modules/juce_audio_basics/juce_audio_basics.h:53,
                 from ../../JuceLibraryCode/JuceHeader.h:17,
                 from ../../../src/common/border_bounds_constrainer.h:19,
                 from ../../../src/common/border_bounds_constrainer.cpp:17,
                 from ../../../src/unity_build/common.cpp:18:
../../../third_party/JUCE/modules/juce_gui_basics/desktop/juce_Displays.h:139:37: note: declared here
     JUCE_DEPRECATED (const Display& findDisplayForPoint (Point<int>, bool isPhysical = false) const noexcept);
                                     ^~~~~~~~~~~~~~~~~~~
../../../third_party/JUCE/modules/juce_core/system/juce_PlatformDefs.h:294:57: note: in definition of macro ‘JUCE_DEPRECATED’
  #define JUCE_DEPRECATED(functionDef)                   functionDef JUCE_DEPRECATED_ATTRIBUTE
                                                         ^~~~~~~~~~~
make[2]: *** [Makefile:110: build/intermediate/Release/common_24cbed85.o] Error 1
make[2]: Leaving directory '/home/pi/vital/standalone/builds/linux'
make[1]: *** [Makefile:88: standalone] Error 2
make[1]: Leaving directory '/home/pi/vital'

Matt Tytel · Answer 1 · Fri Feb 26 2021 02:12:24 GMT+0800 (China Standard Time)

Think there's some other NEON flag in poly_values.h or something.

Filipe Coelho · Answer 2 · Tue Mar 02 2021 16:02:14 GMT+0800 (China Standard Time)

Builds fine on arm64, but fails on armhf.
Error being:

                 from ../ports/vitalium/source/unity_build/common.cpp:18:
../ports/vitalium/source/synthesis/framework/poly_values.h: In static member function ‘static vital::poly_float::simd_type vital::poly_float::div(vital::poly_float::simd_type, vital::poly_float::simd_type)’:
../ports/vitalium/source/synthesis/framework/poly_values.h:592:14: error: ‘vdivq_f32’ was not declared in this scope
       return vdivq_f32(one, two);
              ^~~~~~~~~
../ports/vitalium/source/synthesis/framework/poly_values.h:592:14: note: suggested alternative: ‘vzipq_f32’
       return vdivq_f32(one, two);
              ^~~~~~~~~
              vzipq_f32

Filipe Coelho · Answer 3 · Tue Mar 02 2021 19:50:41 GMT+0800 (China Standard Time)

Possible fix here DISTRHO/DISTRHO-Ports@67cdebb
An alternative code path for armhf is already in the codebase, but was simply not enabled.

If this is all the changes needed, I should have builds that are compatible with rasp-pi in some minutes.

Filipe Coelho · Answer 4 · Tue Mar 02 2021 21:06:26 GMT+0800 (China Standard Time)

It works! direct deb files in https://kx.studio/Repositories:Plugins as usual.

Matt Tytel · Answer 5 · Wed Mar 03 2021 07:09:11 GMT+0800 (China Standard Time)

I'd really like to see Vital running on a Raspberry Pi if anyone can run it.

Filipe Coelho · Answer 6 · Wed Mar 03 2021 07:24:02 GMT+0800 (China Standard Time)

I tried on a MOD Dwarf (so arm64 device with quadcore 1.3GHz CPU) and even at 1024 frames, I could not make any sound without xruns with the included presets.
The default patch does work, but it is not very interesting of course.

Seeing this performance, and taking into mind that the MOD platform runs a highly-optimized RT no-X11 system, I do not think the current release can run on a Pi in any decent form.

Unsurprisingly, vital[ium] runs very well on the apple M1

Matt Tytel · Answer 7 · Wed Mar 03 2021 07:31:35 GMT+0800 (China Standard Time)

Hmm do you know if it's using the fallback FFT in the build? KissFFT (the fallback) is really slow so if it's not hooking into FFTW then it's going to be really inefficient. I think Vital should be fast enough to run on MOD if you have a fast enough FFT on there.

I've been meaning to switch away from FFTW and statically link something in instead anyway. May look into that.

Filipe Coelho · Answer 8 · Wed Mar 03 2021 07:42:42 GMT+0800 (China Standard Time)

I set the juce flag to indicate using fftw as shared library, it seems to be active.

strings /usr/lib/lv2/vitalium.lv2/vitalium.so | grep fft 
libfftw3f.so
fftwf_plan_dft_1d
fftwf_plan_dft_r2c_1d
fftwf_plan_dft_c2r_1d
fftwf_destroy_plan
fftwf_execute_dft
fftwf_execute_dft_r2c
fftwf_execute_dft_c2r

That libfftw3f.so should really be libfftw3f.so.3 though it doesn't change much here as the first is a symlink to the second.
How can we know if juce was able to hook into fftw?

Back when I did some tests for the older Duo model, running 32bit/armhf, the ffmpeg provided FFT was faster than FFTW.
On ARM platforms, NE10 is usually a good choice for this, in case using FFTW is not possible.

Matt Tytel · Answer 9 · Sat Mar 27 2021 07:55:25 GMT+0800 (China Standard Time)

Yeah I really need to replace FFTW.
There's a FourierTransform wrapper that chooses libraries in src/common/fourier_transform.h. Probably wouldn't be hard to extend it to another lib.

I've got my hands full but maybe the next time I'm fooling around on a Pi I'll see about ne10

Matt Tytel · Answer 10 · Sat Mar 27 2021 07:59:02 GMT+0800 (China Standard Time)

Also, I think there are some 32 bit runtime problems, probably to do with memory alignment.
I don't really want to spend time fixing them because 32 bit setups are rare and shrinking.

Filipe Coelho · Answer 11 · Sat Mar 27 2021 15:45:34 GMT+0800 (China Standard Time)

right I can confirm to see issues on a win32 target as well (windows 32bit). the only way I had to make the plugin work there was to use -O0, thus disabling optimizations.