I want to build a realtime wireless audio monitoring for my band's performances. I am not very experienced with Arduino so I am looking for tips and guidance.
At the most basic level, I have an analog input from a mixer, and I want to transfer it wirelessly to 3 devices which should play back the audio via wired headphones.
Latency and sound quality is critical here - <8ms / 24-bit 48KHz would be the ideal end goal.
I am considering using ESM32 for processing, NRF24L01 for transmission and PCM5102 for DAC.
ADC is an issue, I haven't been able to find any affordable ones that give quality any near what I need. I was thinking of using another ESM32 as an ADC using analog sampling, maybe 12-bit would be enough for simple band monitoring. Otherwise I'd definitely prefer to have at least 16-bit sampling.
I'm looking for thoughts, tips and guides before I buy the components and start hacking away so any input is welcome.
This is a very challenging project for someone who is not experienced with Arduino. For wireless monitoring with even reasonable quality audio, buy a professional setup.
I am a software engineer experienced in (soft) real-time programming, I just never had experience with programming Arduino hardware itself.
And I have a friend working with me who is experienced with Arduino.
I am planning on buying a real monitoring system anyway, but I still think it would be fun and I'd learn a lot by attempting to do it myself.
I've managed to get down to ~40ms latency using Sonobus on Android phones over dedicated 5GHz WiFi access point, but the overhead of wireless network and operating system complexity prevents me from getting anywhere below.
I am turning to Arduino to attempt to overcome these limitations.
And in either case there's no need for for latency unless you are using Wi-Fi or other standard that has error & collision detection and correction. With a computer it's multitasking & interrupting that creates a need for buffers, which introduce a delay. (Your operating system is always multitasking even if you're only running one application.)
Do you have any components in mind that fit these parameters?
Unless you were pointing out the impracticality of the idea, in which case LOL.
Perhaps not, but it's easier to keep the quality intact in digital domain. Analog radio almost always suffers from interference and signal loss - digital does too, but that's why retransmissions and buffering exists... which is fine, as long as latency is below a certain threshold where it becomes noticable... Sound itself is very slow in the grand picture - it takes 15 ms for sound to travel 5 meters afterall.
But I'm open to any other recommendations, even completely analog.
You have totally ignored the fact that all Arduino transmissions are individual packets of data with a limited message length. Nothing will happen in your Arduino until that message has been sent and likely acknowledged by the receiving device. Nothing in wireless is real-time, depending on your definition.
Your first study should be the wireless transmission system, not the A/D conversions. Can you transmit data without errors at the required rate so as to make it SEEM to be real-time?
Real-time has a well-defined meaning in programming - having a system behave properly within a given deadline, so that's where I come from. Latency of 8ms is acceptable for audio monitoring, IMO.
In theory, if I use 12-bit sampling from ESP32 at 48KHz, I need to transfer 576 bits per second, which seems well within the data rate supported by nRF24L01. "Without errors" is obviously impossible, but errors are tolerable as long as I can detect them in the receiver and possibly drop them. Perhaps add a couple more bits for checksums, that would amount to 768 bits per second.
Since I need to receive the same signal on multiple receivers, I was hoping to use some broadcast method to avoid having to send to all devices separately.
However given how long ESP32s and NRF24s have been around and how cheap they are, if real time quality 'audio' transmission were possible\practible, there must be plenty of working examples of projects to be found .........................
What do you mean by "rate for a single message"?
My understanding is that rate is defined as amount of data / unit of time... What does "rate" mean in context of a single message?
Yeah my bad. I meant 576 kbits per second. Which, considering the spec for nRF24L01 is well within the supported rate (up to 2Mbps).
Unless I'm completely misreading the spec - in which case, I'd very much appreciate being corrected.
You are correct in the definition, but the manufacturer can only control what happens after the buffer is filled and the command to transmit has occurred. You are thinking this rate is the "system rate", which it is not.
You would do well the determine your own system data rate by writing a program to fill the 32 byte buffer, command the device to send the buffer and then check for completion. Count the messages sent for a period of time and then compute the system throughput value.
so any input is welcome.