Best Linux distro for JUCE-based standalone app


#1

Hi,

I want to demo a standalone JUCE audio app – mainly developed on an OS X System – with the help of an Intel NUC running my app in kiosk mode. In the end, the NUC should boot a lightweight Linux without any desktop environment and just launch my application at startup. Before I’ve gotten there, the linux version of my application should also be compiled on that machine, by simply cloning my git repo and running the makefile created by the Projucer, all through the command-line.

Now, is there any linux distro that’s suited better or worse to this particular use-case? Are there better/worse distros in terms of audio performance?

As I said, I’m usually working on Mac, but when working with linux, I mostly used CentOS until now, so I’m used to it. But I’ve never used it for audio applications & I wouldn’t consider myself to have an overall picture of the linux universe at all, so maybe it’s time to get used to some new linux distro :smiley:


#2

As long as the distro has ALSA (which is pretty much all of them :slight_smile:) you shouldn’t have any problems. CentOS usually has very stable releases and avoids cutting edge stuff, if it works well with your hardware (audio cards) you should go for it.

If you’re into embedded linux, you should checkout the Yocto Project, which lets you build your own custom distro. It isn’t that trivial to get it working, but there are plenty tutorials on the web.
Working with Yocto will allow you to build a cross-compiler, so you can build executables to your target hardware at you dev machine :slight_smile: and generate a linux image with your JUCE executable included by default.


#3

I read several things about Yocto and as I plan to dig deeper into embedded development, it’s definitively on my list to take a look at it.
But for the use case described above, would Yocto give me any benefit? Especially, would I be able to build a cross compiler, that would run on my mac, or would I need to set up a virtual machine with a linux on my mac in order to cross-compile the executable? In this case, I can’t really imagine any benefits over compiling the executable directly on the NUC.

As I just plan to do some fine-tuning for the Linux version (I hope the majority of my OS X implementation is compatible out of the box through JUCE), I thought it might be easy to clone the git containing my code to the NUC, mount the directory containing the code via SSHFS to my Mac and then work on this directory with the tools I’m used to (Projucer & Xcode). Only compiling would then be done by executing the makefile on the target machine instead of hitting compile in Xcode :wink:


#4

Yea… you will need a linux box to use yocto. If you have a mac with some spare ram and a good CPU, you’ll get much faster build times with a cross-compiler.
Well, you’re setup sounds all good. One thing that I really like about Yocto is that you get a very slim and slick linux image, as you can remove all the crap you won’t be using.
But if you’re still at the app dev phase it won’t be much of a difference.
Anyways, I hope I was helpful.


#5

Okay - I set up the system (based on Centos 7 minimal with i3 window manager). My GUI works pretty well, however no Audio devices are detected by JUCE. A call to aplay -l and arecord -l shows me the onboard sound card as well as my externally connected Scarlett 2i2 interface which worked well with other Linux installations before.
In my code I enumerate my devices this way:

StringArray audioDevicesAvailable;
void updateAudioDeviceList () {
    const OwnedArray<juce::AudioIODeviceType> &audioDeviceTypesAvailable = deviceManager.getAvailableDeviceTypes();
    const int numAudioDeviceTypesAvailable = audioDeviceTypesAvailable.size();

    for (int i = 0; i < numAudioDeviceTypesAvailable; i++) {
        String type = audioDeviceTypesAvailable[i]->getTypeName();

#ifdef JUCE_MAC
        // only take CoreAudio
        if (type.compare ("CoreAudio") == 0) {
#elif defined JUCE_WINDOWS
        // only take ASIO
        if (type.compare ("ASIO") == 0) {
#elif defined JUCE_LINUX
        // only take ALSA
        if (type.compare ("ALSA") == 0) {
#endif
            audioDevicesAvailable = audioDeviceTypesAvailable[i]->getDeviceNames();
            std::cout << "Found " << audioDevicesAvailable.size() << " audio devices" << std::endl;
        }
    }
}

This works on OS X and prints a number of available devices >0, however on Linux the number is 0 and my audio application starts without any sound output. Are there additionally steps on Linux I’m missing to identify my audio devices?


#6

You should call audioDeviceTypesAvailable[i]->scanForDevices() , I think.


#7

Good advice, I overlooked that function.
However, I implemented it but this doesn’t solve my problem, there are still 0 devices available on Linux


Setting up a Codeblocks debug session fails
#8

As a developer of applications for embedded devices I have to say Yocto is an obvious choice if you want to have a fully customized system, there are not so many serious alternatives if any. Preparing your own distribution can be time consuming but once it’s set properly JUCE is working without any problems. There are few things which could be included in JUCE for Linux (like multitouch support, video support) but one can overcome it easily. I use another pc with a desktop Linux (Ubuntu + CodeBlocks) for cross-compiling. No problems so far.


#9

I was always reluctant to use Linux for a Juce based synthesizer because of the long bootup times that even the smallest distributions have.
Can you give some info on what is achievable using a Yocto based distro? Thanks!


#10

Well, I’ve been writing the software (or rather rewriting from the old versions I wrote in Delphi and C++ years ago) for the custom designed boards with i.MX6, where Yocto is loaded from the SD card. Bootup time is approx. 10-12 seconds (system load + JUCE based application). I think the final version will be optimized and faster by 1-2 seconds. The key factor is to build Yocto in a simplest possible form. This is a kind of trial and error process (I’m not a system builder and my knowledge is limited here). Reaching the point where everything works as expected is (or can be) time consuming, there are many configuration issues but it’s of course platform specific. If you use some standard board, it may be easier (I assume).