Hi,
I have quite a bit of DSP code already written in C/C++ - some of which leverages the NEON SIMD - which I would like to port to a standalone low latency platform. If I wanted to use this code on Bela, would it be a simple and reading from and writing to ALSA ports to take advantage of Bela's low latency audio, and using standard linux dev tools like gcc?
Hi Andy,
Bela does not use ALSA, because ALSA is an obstacle on the path to reliable low latency performance .
Bela's audio API is minimal and simple, you can get an idea here and, e.g.: here
As you can see, it is easy to add your DSP code in the audio callback render(). If you have functions that may require more than the time of a single audio callback to be executed (e.g.: an FFT), these can run in separate threads (called AuxilaryTask, see e.g.: here ).
Note that the processing is still block-based (as opposed to some bare-metal DSPs which process audio frame at a time), though the block can be as small as two frames. More info on blocks and timing here
Thanks for the reply. The API indeed seems simple. Block processing is no problem. I'm used to buffer sizes of 64, I don't find that to introduce unacceptable delay for my application.
What I don't see in the API is how background processing is handled. For instance, suppose you want to receive control changes over WiFi or Bluetooth?
Just out of curiousity, do you have any longer term plans for more audio inputs? My application is guitar and bass processing. Being able to process individual strings would be really wonderful. That would mean 8 inputs practically speaking.
background processing is handled with the AuxiliaryTask mentioned above, see for instance here how user input is handled in a low-priority AuxiliaryTask.
Currently we have 2 proper audio inputs (at 44.1kHz).
The analog inputs can be used in various configurations: 8 channels at 22.05kHz, 4 channels at 44.1kHz or 2 channels at 88.2kHz. A later upgrade may allow to use 8 channels at 44.1kHz.
These can in principle be used for audio, see here for more details.
jandyman Bela has built-in classes for communicating via OSC over UDP which automatically do the processing in the background for you. The best way to handle background processing manually is to use the Auxiliary Task API (see the use of Bela_createAuxiliaryTask and Bela_scheduleAuxiliaryTask in the example here, and the documentation here).
In addition to the stereo audio input, Bela has 8 analog inputs and it is possible to use them for audio data with a few caveats. Firstly, when using all 8 inputs they are sampled at half audio rate (22.05kHz), however it is possible to use only 4 of the channels and have them sampled at full audio rate. This can be changed in the settings tab of the IDE or in the command-line arguments. Secondly, the analog inputs are DC coupled and have no anti-aliasing filters unlike the audio inputs. This can be fixed with some external circuitry, and to address this we we released an audio capelet as a Kickstarter stretch goal which is an extra cape that sits on top of the Bela cape and essentially converts the analog inputs to audio inputs. It is currently under production, and once we've fulfilled all our Kickstarter orders we are hoping to make it available.
I would say that for your application it should work fine to use all 8 analog channels to read your guitar pickups as most of the interesting parts of a guitar signal are generally below 10kHz, though you will need to build at least a level shifter to bias your signals to around +2V for the DC-coupled inputs.
giuliomoro oops, sorry for the cross post!
I think I understand now. The comments were a little unclear and I didn't get that you could create multiple AuxiliaryTasks.
You can have as many AuxiliaryTasks as you see fit (think of them as threads which are scheduled by Xenomai), so you could have one (or more) for FFTs and then one (or more) for communication.
You can set priority for each task separately, they will be executed in order of priority. Audio runs at priority 95. All the processes on the board which are not initialized by xenomai run at priority 0.
Maybe I'm just being stupid, but one of the problems here is that I'm having problems finding the actual API documentation. So for instance, where are the parameters that one passes to Bela_createAuxiliaryTask described?
Is this what you are looking for ?
http://docs.bela.io/group__auxtask.html
I see that a couple of parameters are missing.
Will add them.
void* args is the argument passed to functionToCall() when it is called, so basically when it is invoked it will be
functionToCall(args);That's exactly what I was looking for! It not easy to find from bela.io! That is, unless my brain is malfunctioning.
yup probably the link from the website is missing. Bela users have a local copy of the documentation living on the board, it is accessible at http://192.168.7.2/documentation/
I like what I see! I'm going to do a project on this as soon as I can clear off my desk from a paid DSP project.
Do you have any long term plans for more audio inputs? I think I mentioned that my long term plans include individual string processing for guitar or bass.
giuliomoro
Currently we have 2 proper audio inputs (at 44.1kHz).
The analog inputs can be used in various configurations: 8 channels at 22.05kHz, 4 channels at 44.1kHz or 2 channels at 88.2kHz. A later upgrade may allow to use 8 channels at 44.1kHz.
These can in principle be used for audio, see here for more details.
I skimmed the material. It looks like the inputs are SARs, which means that you need a pretty good analog antialiasing filter for full bandwidth audio. Mercifully, my first project is bass oriented, so I can afford a wide transition band and build a simple AA filter. Plus I only need 4 channels. Guitar is a little trickier. With conventional magnetic pickups there is again no issue since the bandwidth is really only about to 6Khz, but with a piezo the situation is different. Arguably you still don't need much above 10K and realistically you could do a lot with a simple filter with a 44.1 kHz sample rate. But since you need six channels you'd have to use the true audio codec and the separate SAR ADC together. In that case, will the clocks be synced with each other?
Good to know you are thinking ahead to the true multichannel possibilities. With 8 channels you'd bring in a bunch of guitar hackers. The work you guys have done making Xenomai user friendly for audio is a great thing.
The clocks of the SAR and the sigma-delta converter are synced (in fact the sigma-delta converter syncs the SAR clock). The latency is different, though: the latency for the sigma-delta is
17 samples for the ADC and 21 samples for the DAC. [...] This is why on Bela, the latency from analogue in to analogue out is always lower than the latency from audio in to audio out.
While it is 1 sample (if I remember correctly) for the SAR.
We actually have an expander board (called "audio expander capelet" which provides some analog filtering and appropriate coupling to use the analog inputs and outputs as audio.
To be specific, the audio expander provides 2nd order LPFs at about 18kHz on each I/O. You can always add more stages yourself externally if you like, and if you are only using four of the eight channels, you may be able to jumper two channels in series to get a 4th order LPF.
Also, the (SAR) inputs are easier to use than the outputs from an antialiasing point of view. Whereas aliasing is inevitable from the flash-type DAC regardless of signal, and therefore needs to be filtered, a lot of analog signals are already bandlimited except perhaps for noise. I'm not sure about the response of piezo pickups on guitar, but I can't imagine they extend all that far upward. If you were willing to leave your final bandwidth at 10kHz you can also supplement any analog filter with a high-order digital LPF at 10k to filter out whatever aliasing does sneak in.