Newbie question: best API to port to for running under Elk?

Hi all,

I’m a longtime C++ programmer, but a complete newbie to ELK, so forgive me if this question is very basic.

I’ve developed a simple audio-mix-engine (designed to provide low-latency matrixing/EQ/delays/etc) that currently runs under MacOS/X via CoreAudio’s low-level API (AudioDeviceCreateIOProcID(), AudioDeviceStart(), etc).

What I’d like to do is port this codebase over so that it can run under ELK, so that I can evaluate whether ELK (running on some kind of Linux/x86 box) is a reasonable alternative platform to CoreAudio-on-MacOS/X for this software, and get a feel for how ELK performs for my use case.

My question is, should I start by porting my software to use the JACK audio API? If so, should I target JACK1 or JACK2 (or does it matter?). If not, what audio API should I target instead? (ALSA? RASPA? Something else?)

Note that this software is intended to be a monolithic, take-over-the-sound-card-and-read-input-samples-and-write-output-samples, lowest-possible-latency type of affair; so while I suppose it could be implemented as a plugin, that’s not currently my intent.

Thanks,
Jeremy

Hi Jeremy and welcome to the forums.

It does sound like Elk would be a good fit to your project. Though I would suggest you to think about your reasons for not going the recommended way of implementing it as a plugin that runs in Sushi.

Elk was built as a complete package to take care of all the low level audio details, midi/cv, physical controllers and realtime/non-realtime separation of a realtime audio system - All the boring and hard parts, so that users can focus on dsp algorithms. Hence why you would write the dsp code in the form of plugin in one of a couple of common formats.

There is of course nothing preventing you from making your engine interface with the realtime audio driver directly, which would then be through Raspa (its API quite similar to that of Jack). But you would loose a lot of the benefits of Elk and have to reimplement the missing pieces yourself. And as Elk is already optimised for lowest possible latency, there is nothing to gain in terms of latency by hooking up your own audio engine to Raspa instead of running it as a plugin in Sushi.

Currently the only Elk platform under active development is Raspberry Pi 3/4. If you want to measure the realtime performance of Elk to compare with MacOS, you would need to run it on that platform for a fair comparison. Sushi can run under Jack on a regular linux machine, or even a virtual machine, but the latency would be higher in that case.