Bela vs RPi with Pisound and Patchbox OS

Rich_Sewell

Hi Folks,
I came across Pisound soundcard for raspberry pi and the Patchbox OS distribution [https://blokas.io/pisound/docs/]. These are making some claims about being very low latency, does anyone have any insight into this compared to Bela? Is there something about using the PRU on the Bela that improves latency over what is possible with the RPi? What about Xenomai real time extensions vs the Patchbox OS? Is there an improved beaglebone board on the horizon that will be able to run Bela to keep up with improvements on RPi? I know @thetechnobear has all the answers to this 😉

resynth

Hi Rich, I don't have all the answers but I might have some (with varying degrees of accuracy)

I was actually looking at the Pisound recently and, yes, it looks interesting. I believe it is indeed BBB's PRU's that allow Bela such low latency and, as the Pi is PRUless, Pisound probably doesn't achieve the same performance latency-wise. Looking around the forums I found references to latency figure around 2-3ms (from memory)
Another potential disadvantage of Pisound is the lack of digital and analogue control/sensor inputs. For me that is a big deal.
Also, the OS options don't look as flexible/developed as Bela. I like to work in C++ and the Bela environment is perfect for me in that regard. If you like to work with PD, don't need GPIO, need the extra power of the Pi but aren't bothered about <2ms latency then maybe the Pisound is for you but I feel it doesn't have the flexibility of Bela (or the community)

There is another Pi audio project that claims latency as low as 1ms and has digital/analogue GPIO, Elk audio Pi hat with Elk audio OS. The problem with that is they have no boards available for sale and, even though I've checked a few times over the last 2 years, have never seen the boards available! They have recently added support for the HiFiBerry in their OS however. That gives you similar hardware to the Pisound but with a Juce fork giving you a nice C++ environment with a good, established community. Still, no GPIO so no sensors, pots etc (you could use MIDI but I don't dig the resolution!)

If your motivation is the extra processing power of the Pi compared to BBB then you could wait a few weeks(?) for Bela to be ready for the Beaglebone AI which will offer performance in the same ballpark as Pi4 (not sure which will be faster?). Personally, that's my plan at the mo (though I must admit I'm also asking Elk when they will next have boards available, I might do both systems!)

See: https://forum.bela.io/d/1692-beaglebone-ai-with-bela-cape

Rich_Sewell

I re-read one of the original Bela papers http://www.eecs.qmul.ac.uk/~andrewm/mcpherson_aes2015.pdf and it answers this question in section 3. Unlike other embedded audio systems, Bela puts the priority of the audio thread above the Linux kernel, and therefore cannot rely on the kernel audio drivers (i.e. ALSA). The PRU audio drivers are then used instead which are independent of the kernel.. nice. I think this is the essence of what makes the Bela different and better, is that user audio thread is higher priority than the kernel, and is probably the only way to guarantee against random under-runs at low latencies. The other audio systems seem to still rely on some form of kernel ALSA driver?

Good to hear about the extra processing power in the pipeline with the BB AI.

ryjobil

Bela can get down to 2 samples buffer for the analog I/O @ 44.1kHz (theoretical delay 0.091ms)
http://eecs.qmul.ac.uk/~andrewm/mcpherson_aes2015.pdf

Look at Page 5.

The prominent source of latency for high quality audio is the audio CODEC latency itself, which has nothing to do with the BeagleBone, but the BeagleBone PRU and Xenomai make it possible to reduce latency to the point where the ADC/DAC hardware dominate in latency. If lower latency is the top priority, then using the ADC and DAC channels is the way to go (0.12us).

Audio latency is not the only metric for "audio quality". Some is the noise and linearity (high fidelity qualities of the ADC and DAC implementations), including sample clock stability. Some is due to CPU capabilities (e.g. 16-bit fixed point processing vs 64-bit double precision floating point processing). Some is the CPU horsepower -- for example higher quality DSP algorithms can be implemented in faster processors with better floating point units and lots of RAM.

I don't have time right now to do a good comparison on all these aspects with PiSound, but these should all be considered when making a comparison. Low latency is the strength of Bela, but other platforms may be worth considering when latency is less important than some other feature of a different platform.

For example (in contrast), with a PC often DSP modules can make use of the GPU for speeding up complex algorithms or implementing really long convolutions (even if not in real time).

konsumer

I don't have a Bela, but do a lot of stuff with pi & pd and have a pisound. I really like the Bela platform, and will probably get one soon. I found this thread because I was trying to compare the same thing! You can still do digital GPIO with a pi (it has it's own GPIO) and with other things, like port-expanders (ADC to i2c) you can do analog IO. It's not as convenient, but definitely doable. As an example, I made 3 i2c drivers for plain pi here. Here is an external for digital GPIO & mcp3008 (cheap i2c ADC chip.) I think Bela is nicer to work with on pd (scopes, direct use with adc, easier gpio setup) and has less latency, but it's definitely doable on pi, with or without pisound.

In terms of OS choices/versatility, you can use whatever you like. The "driver" for pisound is just a kernel overlay that is available on any pi os, and I use mine with plain pi os lite or full pi os (not patchos.) C++ (and python, nodejs, and any other language supported in linux, which is pretty much all of them) is totally fine on pi, and there are a lot of libraries. I like WiringPi in C/C++ for plain GPIO, and for i2c, I use the regular linux kernel stuff (libi2c) which you can see in above code. Often python is easiest to work with, because there are more examples (and adafruit + community put a bunch of work into nice circuitpython bindings & drivers for pi) but C especially, also has really good support & libraries (like several choices for how to do GPIO, for example.)

eyeversuseye

I just had a bela project fry, leaving me with a maybe working bela + mult for the Pocket, but no chance of replacing the pocket since it's discontinued.

It leaves me wondering if Bela is at the point where it needs to jump ship to another hardware platform, or if pisound is the successor of it. Which is a shame, because I've loved using bela

giuliomoro

BelaMini starter kit is still available on our shop in case you want to replace it. We may even have a spare pocket beagle to send you but desoldering your board is a daunting task without the appropriate tools.