Bela is a cape for the BeagleBone Black that’s aimed at artists and musicians. Actually, the cape is much less than half of the story — the rest is in some clever software and a real-time Linux distribution. But we’re getting ahead of ourselves. Let’s talk hardware first.
First off, the cape has stereo input and output as well as two amplified speaker outs. It can do all of your audio stuff. It also has two banks of analogue inputs and outputs, each capable of handling eight signals. In our opinion, this is where the Bela is cool. In particular, the analog outputs are not Arduino-style “analog outputs” where it’s actually a digital output on which you can do PWM to fake an analog signal. These are eight 16-bit outputs from an AD5668 DAC which means that you can use the voltages directly, without filtering.
Then there’s the real trick. All of these input and output peripherals are hooked up to the BeagleBone’s Programmable Realtime Units (PRUs) — a hardware subsystem that’s independent of the CPU but can work along with it. The PRU is interfaced with the real-time Linux core to give you sub-microsecond response in your application. This is a big deal because a lot of other audio-processing systems have latencies that get into the tens of milliseconds or worse, where it starts to be perceptible as a slight lag by humans.
The downside of this custom analog and audio I/O is that it’s not yet supported by kernel drivers, and you’ll need to use their “Heavy Audio Tools” which compiles Pd programs into C code, which can then drive the PRUs. Of course, you can write directly for the PRUs yourself as well. If you just want to play MP3s, get something you have a bunch of simpler, better options. If you need to do responsive real-time audio installations, Bela is a way to go.
The project is open-source, but we had to do a bunch of digging to find what we were looking for. The hardware is in zip files here, and you’ll find the software here. The demo projects look/sound pretty cool and their Kickstarter is long over-funded, so we’re interested to see what folks make with these.
Good stuff!
A nice alternative with a similar target audience is the Axoloti (www.axoloti.com). It runs the compiled audio code directly on a STM32F427 without the hassle of running a full linux system and comes with its own open source graphical development environment and compiler.
I’m in no way affiliated with the devs, just got one recently and I find it really cool!
Both are really cool. The Bela folks say this in their FAQ: http://bela.io/faq.html#7
Short version: Bela has Linux, more real-time. But tied into Pd.
How have I not heard of this project before now?!?! I need to buy one of these immediately.
Nice! So finally the BBB can be used as an oscilloscope :)
I’m interested in the synchronisation (phase matching) between different channels on the analogue input. From the datasheet of the ADC used for analogue input, it says, “The AD7699 provides the user with an on-chip track-and-hold and does not exhibit pipeline delay or latency.” Can someone confirm that this means samples from each of the multiplexed input channels of a waveform applied to all channels will be effectively be in phase?
I.e. if a sine wave is applied to all channels, and they all make samples from it in turn, will the resultant digital representations all be in phase, or does some delay correction need to be applied? I would hope that there is a separate sample and hold for each channel.
If you look at the datasheet for the AD7699 (http://www.analog.com/en/products/analog-to-digital-converters/ad-converters/ad7699.html) it is a single ADC with a mux upstream. I haven’t used the part, but unless they’re hiding something, it’s going switch between channels in sequence — so there’s a necessary delay between sampling times.
The “no delay / latency” is probably between the ADC itself and the I2S / I2C data availability.
If you want phase-accurate sampling, put eight sample-and-holds upstream and trigger them from a common signal. Then you can swap between the eight channels at your leisure.
Yes, that’s what I was hoping wasn’t the case. I did hope the phrase I quoted meant that there was a separate sample and hold for each channel in the multiplexer.
Bela dev here, the sampling of the analog ADCs is definitely NOT simultaneous. In the 8-channel configuration you have roughly the following latencies with respect to the first ADC:
channel 0 : 0
channel 1 : 2us
channel 2 : 11.35us
channel 3 : 13.35us
channel 4 : 22.7us
channel 5 : 24.7us
channel 6 : 33.05us
channel 7 : 35.05us
Basically even channels are sampled at 88.2kHz ( in total), while odd channels are sampled as soon as the previous even channel is done.
That’s how we can achieve 8 channels at 22.05kHz, 4 channels at 44.1kHz or 2 channels at 22.05kHz
Now the beaglebone guys need to send a couple of boards to the Reaper guys if they want to get serious about this. Reaper is about to come out for the Raspberry Pi 3 and supposedly will be insanely capable. The BB should do what they can to get Reaper on board with builds for their board as well.
I totally second that. Reaper (http://reaper.fm) is a wonderful piece of very well crafted software, a true gem that surpasses everything else in a feature vs size ratio and is very nicely priced. Also it works wonderfully under Linux with WINE and ASIO emulation; it allowed me to ditch the last two Windows PCs, a tower and a laptop, that I was forced to keep for making music.
Looks a lot like this FOSS project, https://ardour.org/
I knew about Ardour since one had to compile it because there was no package for most platforms, that’s years ago, and didn’t try it for a while so I might have missed some development. My opinion is that Ardour feature wise is surely on par with Reaper, but lacks “something” in usability. I can’t say what is the problem but I felt uncomfortable with it and found Reaper much more immediate to use. Note that I’m not a pro musician, I make just some tunes now and then.
This is roughly a similar reason why I prefer editing waveforms with the >15 years old and now free Cool Edit pro v.2.1 under WINE rather than Audacity.
Nice, now I just need a compact way of selecting pre-sets and a few extra parameters for this, http://guitarix.org/
Makes for an interesting UI design problem. For initial set-up you can use whatever system you like and then transfer the library, but for performance you need something more compact and robust.
Isn’t the deal with audio is that while 16/48 is plenty good for output if used properly, 24 bit and 96kHz or better are very useful for input by making the gain setting far less critical and reducing the chance of aliasing?
Something like that, yeah. I’ve read claims that go both ways, but my takeaway is that 16/44.1 (or 48) is plenty for the master, but if you’re mixing and processing, the extra bits and sample rate can make the signal cleaner up to that point.
Basically, what you said.
Hi, Bela developer here, thanks for your article.
I have a couple of comments on this:
`this custom analog and audio I/O is that it’s not yet supported by kernel drivers`
true that it is not YET supported, but it must be pointed that it will NEVER be, because the whole high-priority audio needs to run independently from the kernel.
`you’ll need to use their “Heavy Audio Tools” which compiles Pd programs into C code`
We also support libpd, so there is no need to use Heavy.
`Of course, you can write directly for the PRUs yourself as well.`
This makes it sound as if you have to write PRU assembly. In fact you do not have to. There is a simple C and C++ API that would be immediately familiar to who is experienced in developing for other platforms.
Also sorry for taking it long to find the documents.
Thanks,
Giulio