Not building on Raspberry Pi OS (32-bit)

[m-roberts]

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'

[mtytel]

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

[falkTX]

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

[falkTX]

Possible fix here https://github.com/DISTRHO/DISTRHO-Ports/commit/67cdebbd2472380ac5c4339ac82fba4749b0e6da 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.

[falkTX]

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

[mtytel]

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

[falkTX]

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

[mtytel]

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.

[falkTX]

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.

[mtytel]

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

[mtytel]

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.

[falkTX]

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.