[Announcement] JUCE support for Embedded Linux


#1

Hi all,

I would like to share here some news regarding JUCE and Embedded Linux: I have upstreamed JUCE support for the OpenEmbedded (also Yocto) build system for Embedded Linux! All the JUCE related work is already upstreamed as well. :grinning:

Introduction

I would like to introduce myself since I am quite new here. My name is Felipe Tonello and I work at ROLI mainly on Audio for Embedded Linux. (check out the Seaboard GRAND for a really cool Embedded Linux device running JUCE!)

Embedded Linux support is all about building. Besides the architecture support that most libraries and system developers have to worry about, application developers care about how to build to a different platform other than the one they are using. This task is quite complicated so I will not discuss it here. And that is why we use build systems - tools developed in order to solve that and many other problems.

Important: This post considers that you are running on any major GNU/Linux distribution and have an OpenEmbedded (or Yocto) setup done.

How to build

There are two ways to cross-compile your application:

  1. Using a build system (for production)
  2. Using a SDK (for development)

Build System

Here I provide some of the basics in order to build your application on a build system, considering you already have an openembedded (or yocto) environment setup:

  1. Add the meta-multimedia layer from meta-openembedded repository to your build configuration.
  2. Create a recipe for your application containing the following skeleton:
inherit juce

JUCE_JUCERS = "${B}/cool-project.jucer"

SRC_URI = "git://path-to-my-repo.git"

do_compile() {
  cd ${B}/LinuxMakefile
  CONFIG=Release oe_runmake
}

do_install() {
  install -D ${B}/my-binary ${D}${bindir}/my-binary
}

A little explanation

The first line is where the magic happens, inherit juce will perform all the basic dependency configuration for the build. The bbclass for that can be found here. That class defines two main variables that application recipes should define:

  • JUCE_MODULES (optional): What JUCE modules your application depends on? It defaults to what the build system supports. Values should be JUCE modules names separated by spaces.
  • JUCE_JUCERS (required): The path of the .jucer your application uses to build. It can be multiple .jucer files separated by spaces.

SRC_URI, do_compile(), do_install() and oe_runmake (runs make with some arguments) are part of the OpenEmbedded build system. install is a normal Unix command.

SDK

For SDK builders

In order to add JUCE support to an OpenEmbedded based SDK, add nativesdk-projucer dependency to TOOLCHAIN_HOST_TASK like this: TOOLCHAIN_HOST_TASK += "nativesdk-projucer"

Build your SDK as usual.

For developers

Install the SDK previously built and source the environment file that comes in it.

On the terminal (where you sourced the environment file), you will notice that Projucer will be accessible on the current $PATH, which means that you can type Pro<TAB><TAB> and the shell will autocomplete to Projucer. Then you can just run Projucer --resave my-application.jucer (or even without --resave, which will open Projucer’s window) normally. Just cd into the directory where the Linux Makefile is and run make. Your cross compiled binary will be ready in a short time.

It is that simple! :grin:

Conclusion

This makes things really easy for Embedded Linux development with JUCE. And yes, some Embedded Linux knowledge is required in order to setup a build system, but that can be the work of someone else. :wink:

If you want to know more

Make sure you attend ADC 2016 because, among many other reasons, I will be presenting a talk about Audio Application on Embedded Linux!


Run JUCE on Intel Edison?
Channel assignment changes in audioIOCallback on the fly? (arm / linux)
#2

This is exciting stuff!

Can you recommend any inexpensive, off the shelf prototyping boards (known to work well, that is)?

Best,
Ben


#3

Hi Ben,

Sure. The OpenEmbedded build-system (used by the Yocto project) is widely adopted by the Embedded Linux industry.

Here you can find several BSP (Board Support Package) under the Yocto Metadata Layers section.
At ROLI, we use the meta-fsl-arm BSP which supports all Freescale’s SoCs and machines, such as the i.MX6Q SabreSD (base for the Seaboard GRAND).
There are also community and official support for other machines such as:

NOTE: All items below are links to each respective BSP, but for some reason this forum doesn’t show them as links on a bulleted list.

and so on…

Back to the recommendation: they are all development boards that suppose to support a range of functionalities, such as a decent multimedia support, specially SIMD instruction set.

Raspberry Pis

The Raspberry Pi seems to be the easiest to recommend due to its adoption and more likely to have a bigger community around to try out your application or maybe to help you out.
The downside is that the audio hardware is terrible - basically non-existent. If you want a good audio support you need to add a codec expansion board, such as the Cirrus Logic Audio Card.
Its 3rd version has 64bit 4 core ARM CPU with Wi-Fi and BT 4.1 (more on this below) integrated, which is really cool.

TI’s boards

I have also used BeagleBoards, their Linux support is also really good too but less powerful when compared to the Pi. The BeagleBoard Black has a nice feature which is the Programmable Real-time Unit (PRU) - it can be used to handle real-time interrupts among other things.

NOTE on Bluetooth Low-Energy: I have been working on supporting the MIDI over BLE specification on Linux. Which means that, once is upstreamed and released, all these boards will support MIDI over BLE out-of-the-box.

I hope that is useful.

Cheers,
Felipe


Embedded synthesizer
#4

Hi!
are there any plans to support Wayland for graphics output?

Thanks!


#5

No, not at the moment. :frowning:


#6

Is it possible to make full screen Linux application without X11 overhead (and possibly with HW accelerated OpenGL ES)?

I’m using i.MX6Q SabreSD and performance with X11 is poor.


OpenGL on Raspberry
#7

It is. But that is unrelated to JUCE.

You just need to start an XServer and run the application, set the position and size to appropriate values.

This could be anything, I can’t judge without looking into your environment.


#8

Hi,

I got everything working fine for my hobyist project on a raspberry pi 2.
My Juce based app (a chess UI) boots directly under X in full screen mode with a working touch screen.
It targets a raspberry pi 2 with a 5 inches TFT HDMI display (35€ waveshare model).

I spent quite an amount of time to have this working fine, so i thought i was a good idea to share my meta layer.
https://github.com/Ixox/meta-xavier

The image (recipes-core / rpi-image-timochess) is not really minimal but it boots quite quickly (20s). I cut it down to 12s by tweaking /etc/rc5.d.

Once you have flashed your image on your SD, in conf/ you’ll find a little script that deploys the Juced app rpm on the raspberry pi, kills the app and relaunch it from your PC.
So code and test your app on your PC.
When ready : bitbake your recipe (crosscompile) and deploy in 5 seconds on your raspberry pi2.

JUCE + YOCTO + raspberry pi 2 is a fantasticly fun combo !

Thanks Jules, Felipe and Team,

Xavier


#9

I put something like this together also, but using Buildroot instead. Here are all the files and a pre-built image:

I also recorded a little video that shows how fast this boots and what it looks like:


#10

Hi,
did anybody suseccfully follow the instructions of @ftonello withe the current meta-openembedded ?
To me it seems to be brocken with Juce 5.
I can`t bitbake nativesdk-projucer or bitbake projucer-native.
I allways get errors like I described here.
Any help is very welcome. Thanks


#11

JUCE does not officially support yocto and we rely on the yocto community for keeping it up-to-date. I’ve reached out to the original author of JUCE’s yocto support and I’m hopeful that he’ll fix this. Let’s see…


#12

As a short fix you can disable the webkit gtk support of JUCE.

I believe we should disable Webkit support for JUCE on embedded by default. If the user really wants this, it can enable. What you guys think? This will be done in the bitbake recipe, so no need to change JUCE.


Yocto - "bitbake projucer-native" gives pkg-config error?
#13

Very good idea.


#14

The webkit gtk support is only really used for the Projucer. So it should be enabled on the host but not on the target.