OSX, VirtualBox, & Mind Development Kit Linux Image Performance and Stability

Elk Audio OS Plugin Development
1

Any recommendations/suggestions to improve performance with development and testing on an OSX host?

When I use the Mind Development Kit (Linux) Image under virtualbox, the Lubuntu UI often becomes unresponsive and/or the VM crashes when performing even the most basic tasks. When I play a clip in audacity the UI is not responsive until clip ends. Not much else is running other than Jack, Cadence, Carla, Catia, and Audacity. Load on linux and osx top as well as Jack DSP load is low. I shudder to think what full on development would look like in the VM.

  • Are there settings for virtualbox or lubuntu which would help out? Audio driver, # cores, ram, etc? (Currently using 4G, 3 cores, VBoxSVGA with 128M, Core Audio, ICH AC97)

  • Any changes to the dev or test tool chain for development that would help?

FYI, I updated all the packages in Lubuntu, am running the latest version of virtualbox, have the vbox addons installed, and am on the latest version of Mojave. Sadly Docker on OS X does not support audio. Don’t want to dual boot to Linux. Just setup the new Mac about a month ago, so a new Linux machine is out. Wondering if a PI3 based system would be a better experience than the vm running on a new 2019 MacBook Pro. :frowning:

Thanks in advance for any help!

2

Hi! Im using a mac to develop as well. I’m using a late 2013 retina 13-inch macbook pro for development.

Currently I’m running the VM in VirtualBox with these settings:

  • Base memory = 4096 MB
  • Processors = 2
  • Video Memory = 32 MB
  • Host Audio Driver = CoreAudio
  • Audio Controller = Intel HD Audio

I also had some problems with the VM gui running really slow. The workaround I found was to run VSCode and connect to the VM as a remote server. This provides a native IDE-like development experience without the hassle of moving files back and forth. The only time i used the gui of the VM was when configuring the projucer or doing a more involved audio routing in jack. I found that for basic audio routing running sushi with “–connect-ports” works pretty well. I you need audacity for analysis you could probably set up some kind of shared folder between the host and the guest and do the analysis/processing natively as well. A cool feature that I found with VSCode is that you can connect it to gdb on the VM and graphically debug your application like you would in Xcode.

I do have quite a bit of latency when running plugins in sushi on the VM but since this is not the end target platform I find this is enough to verify that the plugins are working and running as expected before I move them to the dev board.

Hope this helps :slight_smile:

2 Likes
3

So I got a DM asking further about my development workflow on OSX and I thought that I would put my answer here in hope that it helps everyone.

So the work I did was to port the plugins that are pasted here on the forum to elk. Most work was done by cloning the repository to the VM then accessing and modifying all the code on the VM with the VSCode interface running natively on the mac which gives the full retina experience and responsiveness of a mac app. However, the files were never actually moved to the mac. I’m not sure exactly how it works but VSCode can make some kind of server client setup over ssh. The when I built the plugins they were also built on the VM, which is a bit slow but works. The built plugin binaries were tested using sushi on the VM and then they were cross compiled and tested on the dev-board.

Only in a few rare cases did I get the plugin repository on the mac and did a local build but you could of course start natively. Especially if you’re developing your own plugin.

For building and testing my own plugin projects I currently use JUCE together with Xcode. JUCE comes with the source for an app called Plugin Host which is kinda made for testing plugins. It hosts audio units, VSTs and probably a few other plugin formats. When everything seems okay with the plugin I usually move on to test it with Logic Pro X. Another perc of using JUCE is that it is pretty easy to then cross-compile it for ELK. Granted you have solid separation of the plugin view and the plugin model.

Hope this helps :grin:

2 Likes