aplay, sox, or similar for Bela, but taking advantage of the latency?

akjmicro

Hi all,

I'm wondering if applications like aplay, which work in a "normal" way in a non-Bela Linux environment, have either a slightly re-written version for Bela that takes advantage of its tight kernel buffering loop, or if there is an equivalent to aplay that takes advantage of Bela's scheduling?

Could also be something related, like sox. I have a special DSP lib I'm developing for my RPN stack-based language called dclang (https://github.com/akjmicro/dclang/), and to mess around with sound on Bela, I'd like to be able to pipe stdout to the stdin of an sound CLI app that takes advantage of the low-latency.

Thanks,

Aaron

giuliomoro

OS-buffered pipes are antithetical to low-latency. One could relatively easily write a program that takes stdin and produces stdout and internally uses the Bela API, but there is no way to do this in a low-latency way.

akjmicro

Got it....sounds like the way forward for me then would be to use the Bela API linked in locally with a function that loads to the Bela buffer directly.

[edit] My current working flow with my language doing DSP-related things was writing to stdout and the buffer of aplay would be taking that in. Each loop of a DSP function calculates a single sample (and believe it or not, does this quite well for an interpreted language!) So, would I be able to have something (targeting the Bela API) "slurp" up a buffer-load of the output of my otherwise sample-at-a-time calculations? I would like to minimally alter the basic codebase of my language, but instead create the buffer aspect as a handshake.

If this isn't optimally possible with stdin/stdout, is there a mechanism by which Bela could grab sample created by an external program? Would this have to be a shared memory situation, then?

akjmicro

@giuliomoro I wanted to follow up here: I believe I figured out what would be needed: essentially, if I ever want to use dclang with Bela, there would be likely 3 changes:

Invert control and grant main control to render, such that the tight inner render loop calls a C-API to talk to dclang. I.E., per your earlier comments, it's not feasible to pipe audio data into a stdout/stdin situation in an extreme low-latency environment like Bela. although it worked with aplay on a normal Linux commandline situation, that was likely because the hidden buffersize was large enough automatically with defaults that it avoided glitching.
Given that for some of my "interpreted" DSP functions need 4096 samples in a buffer with a proof-of-concept in portaudio, it's likely that I'll also need to not write the bulk of the computations in dclang, but have dclang loosely wrap most of the computations happening at the C-level (i.e. a dynamic lib primitives situation). This is similar to Python's relationship to pyo.
Hacking on the scripts and Makefiles that bring up an executable bela project, with the correct import and library paths. Is there documentation somewhere on what's involved in creating a brand new "project type" in Bela so that its deps can be brought in. by new "project type" I mean simply: not C/C++, Csound, SuperCollider, Faust, or PD....but a new pattern, the closest which would be C/C++ with custom lib deps.

Thanks in advance for your help here,

Aaron.

giuliomoro

This could be of help for the overall task of integrating the Bela core with another program https://learn.bela.io/using-bela/advanced-topics/using-the-bela-core-with-other-programs/

akjmicro s. Is there documentation somewhere on what's involved in creating a brand new "project type" in Bela so that its deps can be brought in

no documentation as such. As you can tell there, the project type is inferred from the files that are present in the folder.

akjmicro so that its deps can be brought in

I am not sure I understand what you mean here: is all you need to add some shared libraries? What does the build process for your type of project look like?