My Questions: - if someone can kindly respond to all of them if possible
Q1. Since this will be a commercial product, can I use the Elk OS without the Elk HAT. I want to design my own 16 channel audio HAT with Texas Instruments. Will the Elk OS pick it up? - reason being I am asking if I can use the Elk OS is because it is built for low latency and I need it in order to process real time audio which will be used for personal monitoring.
Q2. Can I use SUSHI to receive multi-track analogue inputs (in my case it will be 16 channels), allow the musician on stage to create a personal monitor mix via bluetooth/wifi with MIDI, add basic effects (e.g. reverb) and then let Sushi send the mix out again to the Spark chip or something similar.
Q3. Since I will be using 8 wireless stereo beltpacks which will connect to the host PI via wifi/bluetooth/SparkChip, Sushi must be able to create 8 individual instances/mixes and output each one of them to a separate Spark Chip or something similar - is this possible with Elk OS?
Q4. Perhaps I can use Cabbage/Csound on the ElkOS to do Q3?
Very much interested in a low latency, high quality, stereo wireless monitoring setup. 5-7ms might be tolerable (or a tad too much) when combined with other latencies in my system. Elk is likely overkill beyond a demo board. Most interested in a two channel (stereo) version at a prosumer price point. This is an untapped market.
That chipset looks interesting. The broad spectrum and low power could be an improvement over 2.4/5 approaches. I would think the broad spectrum approach would add a tad bit of latency, but who knows.
It has “down to 3ms” latency; the demo board says 5ms (which I assume includes -2 ms for AD/DA on one side)?
I doubt you could get all 16 channels TX/RX on one chip at a time. Might be able to multiplex with more latency, but even that would be a stretch. If you had 8 chips on the base station, there’s probably a limit on how many could be active at one time in the signal area … and likely a limit as to how close those 8 antennas could be placed.
Will you kindly explain what you mean by “Elk is likely overkill beyond a demo board”. Do you mean Elk OS? Do you rather suggest I use a Linux OS with a real time kernel and build my own audio app with csound from scratch which runs on ALSA? If you suggest that, can you refer me to a specific Linux OS you recommend for my project? And would csound do the job?
*I though of using Elk OS as it is already tuned for real time audio?
So if I understand correctly, if I use Elk OS without the Elk Hardware, I will need to write custom drivers. So if I use my own audio chips from Texas Instruments, and my own wireless chips from Spark, I need to get help from the Xenomai guys to write drivers for those two chips to work with the Elk OS? Do I understand correctly?
I skipped the part where you said you would build your own hat. My bad.
That said, do you really need a microprocessor for transmitting multiple streams of audio over wireless. It will work, but for that application do you need the power of the hardware device?
It sounds like you could use a DAC->wireless without much in between. Now if you could multiplex the wireless, want to have some type of digital mixing, or EQ that might suggest something more powerful.
The benefit of the Raspberry PI is that it streamlines development.
You will need to adapt the audio driver for that TI audio codec. It’s a work that we can also do under paid consultancy.
If you’re releasing a commercial product and don’t want to release your sources as well, you’ll need to get an Elk commercial license. Write to tech@elk.audio for more information.
Both should be possible in a relatively easy way.
Probably not a great idea. Cabbage / Csound support is experimental and besides, it’s a plugin in a single track. If you need mixing and routing, it’s better to just use SUSHI itself.
