I have a couple of Bela’s and am looking for something with a bit more processing power. The pisound looks good as I’m hoping the pi4b should give me significantly better performance than the beaglebone black. I would go right ahead and buy but, despite reading around, am still unsure what “low latency” means in respect to the pisound?
The website and docs don’t seem to quantify it and forum posts seem to suggest figures between 4ms to 10ms? I am familiar with setting ADC/DAC buffer sizes and sample rates and understand there is no fixed figure for throughput latency but would like an idea of what is possible.
I tend to run Bela with latencies around 1ms or 2ms ish depending on patch complexity, is that possible with pisound?
What are the lowest latencies theoretically possible on pisound? (I know that is processing dependant, just trying to get an idea)
Not looking for a debate on whether these magnitudes of latencies are noticeable or reminders of the speed of sound, thanks
Thanks for that Gledrius. There seems to be a wide variation in the test results.
You get 3.6ms round trip latency with 64 samp buffer @ 48khz
Son gets 7.6ms round trip with pd running 64 samp @ 48khz
The linked website claims 0.9ms @ 48khz
Hard to know which result to trust?
The pd result suggests patchboxOS is implementing some fairly sizable software buffers?
Patchbox OS does not really do anything special, it’s just an OS image with a preconfigured set of packages. Jack backend is the one usually used by audio applications.
It’s best to compare latency measurements when measured using the same method. @edwillys calculations in the linked thread are correct, and we can see that in practice, the expected latencies match up.
Keep in mind that lower latencies can be achieved if using 96k or 192k sampling rates.
How was this latency measured and with what audio settings?
With Bela measuring is less necessary as you can work it out. The code for the programmable realtime units is fixed and guaranteed. The os is xenomai and the audio blocks are hard realtime, guaranteed on time. The datasheet for the TI codec tells you buffer sizes/latency for the codec. You choose your buffer size in Bela and do the maths as everything is known. There is an oscilloscope included which you can use to confirm the results. I’ve also tested it using my RME HDSP which I’ve used for measuring latencies of Axoloti and Elk pi hat too (among others). Some people say you can’t accurately measure latencies with a sound card / DAW which I find odd as the measurements I get not only match expected results but also match what I see with my digital oscilloscope (that I hardly use as it only works in windows!). For measuring in the DAW I use a dirac on the timeline, loop an output, through the device back to the input and record. Doesn’t give results accurate to 0.001ms but good enough for my purposes!
Bela will theoretically operate with latencies lower than 1ms, as will the Elk pi hat. Of course I’ve never had that in a practical situation as we need to do some processing! Still, on Bela I can do about 5 seconds of stereo convolution with latency under 2ms.
The problem is I want more power than is provided by the BBblack Bela runs atop but I don’t want to sacrifice on latency (it’s not the only latency causing digital system in my audio path!)
My use case for pisound is for convolution, violin instrument body emulation followed by reverb by fft convolution. When I reached as far as I could go on Bela I got an Elk Pi hat which I am also developing on in C++. I was hoping the pisound might provide a good stop gap and experimenting platform using pd, C++ dev in Elk OS is quite an involved process and I would like something I could gig with now.
