Has anyone got Juce working on the raspberry pi?
Yup. Works fine. There are quite a few dependencies, but it works well. Compiling is the main problem - you have to make a decent size swap or the compilation will fail.
In ProJucer, set the copy modules mode to yes, and you can put a whole folder on the Pi then compile.
The last time I tried compiling on the pi using clang was much faster than gcc, so I’d give that a go too.
thx for the tip Tom, will bear that in mind
FWIW we’ve had Tracktion running on the Pi for quite a while now
Hi Jules. A custom linux distro is mentioned there - is this something we have access to? Is this beneficial for us running our own linux apps?
No idea what the distro is, TBH. @dave96 ?
It’s not really a custom Linux distro, it’s Ubuntu Mate 16.04 I think because that’s closest to our main Linux distro so was quite easy to target.
We distribute the whole distro with Waveform installed though which is probably what’s referred to here.
ok, thx for clarifying
I just successfully built a simple Juce-based command line tool on a Raspberry Pi 3. I did this with a normal Linux Makefile exporter and wanted to set the Architecture flag there to ARM v8 as the RPi 3 has a 64 Bit ARM v8 CPU, however, there is just an ARM v6 and an ARM v7 option. Is there any reason for that? What settings are recommended?
All works amazingly well on Ubuntu, but I have to remove clang from the make command in terminal and from any install script(a script nicely provided by a JUCE user). Am i correct in assuming not using clang does not matter?
I am using terminal make to build projects. I have not had any luck with code blocks(terminal is ok as I design on a mac first). Any hints for setting up codeblocks on raspberry pi linux? I have codeblocks installed, but it is not building the JUCE projects.
In the JUCE demo internet is not working for me or in firefox(works in Chrome) since installing the suggested dependencies. Any further thoughts?
Almost finished building my first DAC from scratch. I would have only dreamt about this a couple of years ago.
I don’t think there’s a reason for that, other than it’s not been updated for a while. Is the required flag
It shouldn’t matter which compiler you use out of of clang and gcc.
What errors are you seeing when attempting to compile with Code::Blocks? If you don’t give us any more information we’re going to struggle to work out what’s going wrong!
JUCE_USE_CURL=1 in the preprocessor definitions in the Projucer. cURL is much more robust than JUCE’s inbuilt networking.
We’re trying to use JUCE on Raspberry Pi with a Raspbian distro. Everything compiles and works fine except OpenGL. Our app uses the OpenGL renderer for both 3D and UI rendering with an attached OpenGLContext to the top level component.
When Raspberry emulates GL on the CPU everything works, but (not surprisingly) terribly slow. When hardware acceleration is enabled we can see a few frames to render and after that the app just stops responding. You can check it with the JuceDemo too, it’s the same behaviour.
When we run the GLX Gears demo (one of the default MESA tests) it runs on stable 60 FPS forever.
Any tips on this? Thank you!
Anyone doing some cross-compiling?
I really wished I could compile from Xcode directly or even with cmake but from my main machine.
Seems most of what I’ve found is based on Qt for those who like using IDE.
P.S. - Raspbian is 32-bit and from all I’ve read for audio Ubuntu Mate is one of the most fitted performance wise.
Thanks for the JUCE_USE_CURL=1 preprocessor definitions tip. The web browser now works like a charm.
The first basic question is does the JUCE demo in Projucer set up code blocks or do I have to manually change things like the compiler setting in code blocks to arm, etc? The error I am getting in code blocks is
- g++ error unrecognized command line option nstackrealign
Thanks so much
I think it should be
What happens if you remove
-mstackrealign from the compiler configuration in Code::Blocks? Are you then free from errors? If not, what compiler are you using? Can you compile using the Makefile?
I’m not sure why that flag is there - we don’t add it to the Makefiles, so I don’t think we should be adding it to the Code::Blocks project.
Actually, if you’re going for performance, it looks like you probably want all of
CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -ftree-vectorize".
All that info is fantastic.
I am compiling using makefile. It works well.