1
\$\begingroup\$

I want to design an audio mixer that works wirelessly and has a web interface. Here's what I'm generally thinking:

One component is a 1/4 inch plug with an amplifying circuit and a WiFi module which communicates via UDP over the local network to a Raspberry Pi.

Several of these units are connected to guitars, keyboard, microphones, etc.

On the Pi, I have a simple interface running locally in the browser for mixing signals from different instruments and outputting to a single set of speakers from the Pi.

I'm really just looking for some general thoughts from someone who has experience with audio electronics (I have none).

Would Bluetooth be a better choice than UDP? Or maybe even Zigbee?

\$\endgroup\$
2
  • \$\begingroup\$ Take a look at Jack Audio Connection Kit for Linux. Real time audio is a black art - especially where networking is concerned. \$\endgroup\$
    – Majenko
    Jun 16, 2014 at 21:45
  • \$\begingroup\$ I'll have to check this out when their website comes back up \$\endgroup\$
    – Chet
    Jun 19, 2014 at 14:57

2 Answers 2

5
\$\begingroup\$

Music is a special case for audio latency. For speaking, or voice conversations you can have up to 100mS latency before it impedes the conversation - though it can be noticeable at that latency. Music, however, has a beat and 100mS is unacceptable.

When musicians play together acoustically sound travels about 3mS/meter. On a typical stage setup band performers would deal with maximum 25mS of acoustic delay. Larger stages require monitor speakers with maximum 10mS latency so the acoustic delay is always under 25mS.

As long as your system is expected to provide feedback (monitor) to the musicians, and they are close together, or they have low latency monitors apart from your system, and the band is fully amplified - ie, the audience won't hear both the acoustic sound from the band and the amplified sound from the speakers - then you might get away with a larger than 25mS latency for your entire system - from music pickup to speaker output.

However, it's likely that the band can hear the amplifiers, and again any delay greater than 25mS is going to cause them some aggravation.

With small, frequent UDP packets you can meet this over wifi, but it's going to be tricky accounting for all the sources of latency inside such a setup.

Go ahead and do some testing - use one Pi with a microphone, one with a speaker, and both with wifi. Have them simply relay sound from one to the other along the full path, from the mic to the speaker with all the bits and pieces in the middle. Capture very small packets - 1-5mS each at the most - and send them across. Use an oscilloscope to measure the latency. I'm guessing with USB sound devices and USB wifi devices and the stock non-realtime Pi you're going to see very large latencies. You'll likely have to do quite a bit of investigation and work to bring them under 25mS.

\$\endgroup\$
1
  • \$\begingroup\$ bummer man :( I guess that's why it hasnt been done yet... \$\endgroup\$
    – Chet
    Jun 19, 2014 at 14:54
0
\$\begingroup\$

UDP will probably handle the data rate you need for audio streaming, but the latency will be problematic with live audio. Consider the path:

Source -> ADC -> I2C to UDP conversion -> Network -> Audio processing -> Audio output

I've had latency issues with audio when using analog wiring, professional digital interface equipment, and a high end computer. JACK and ALSA tend to be even less reliable, so I'm not sure what kind of performance you'll be able to get out of audio processing on a raspberry pi.

Most professional audio equipment I've used actually goes a different route that you may want to consider: rather than streaming audio to a computer, processing it, then streaming it back out, they have dedicated processing hardware that simply accepts control signals from a computer so there is virtually no latency added.

I think the "proper" way to do something like this would be to use a direct wireless connection (like Bluetooth, rather than relying on an external network) to stream raw audio data to an FPGA with some DSP utilities. The FPGA could be controlled with a Raspberry Pi or something similar through a SPI or I2C interface. There would be a lot more upfront work implementing the DSP algorithms for audio processing (rather than just using JACK plugins on a computer) but it would significantly reduce the latency in the processing stage. Using Bluetooth would also reduce latency in the transmission and reception stages, because it doesn't rely on a (possibly nonexistant, if you intend to make this system mobile) uncontrolled network.

That being said, I think that how you should actually implement something like this depends on precisely what you intend to do with it. Personally, I've wanted to build something like this for a while to simplify setup and teardown for live shows. My current solution is basically to replace the cables with some wireless replacement, and use commercial equipment for all of the processing. High quality mixers are pretty cheap (I also already own a few) and can't really be matched by ad-hoc solutions in terms of sound quality.

The thing that has held me back is the cost. This is the cheapest option I could come up with, and it requires the most upfront work: an ADC capable of audio conversion costs ~20$, a pair of bluetooth chips costs ~10$, and a pair of FPGAs for controls costs ~30$. That's mostly manufacturer spec parts; getting hobbyist equivalents would cost well over 100$, and that's just to replace one 10$ cable!

Back to your project, that's why you don't see wireless audio for instruments; it's prohibitively expensive to get the sound quality needed for making music (most of the common systems are for speaking only, so quality isn't nearly as important). Some purely wireless systems do exist, but they generally cost thousands of dollars, have dedicated hardware for transmission, reception, and processing, and generally use proprietary codecs and protocols.

If you still want to do your custom solution, look into JACK's audio streaming utilities. If you can figure out how to transmit with that protocol, you could plug your signal directly into all of the JACK extensions. You could then just download a JACK mixer to handle all of the processing an output.

\$\endgroup\$
1
  • \$\begingroup\$ FPGAs are awesome, but a lot more work... \$\endgroup\$
    – Chet
    Jun 19, 2014 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.