Multiple WiFi Audio Streams

[digital11]

So I'm kicking around a project idea that would involve taking multiple (probably 4 or 8 to start) line-level unbalanced mono audio inputs and multicasting them to many smartphones simultaneously via WiFi. The device would create its own 802.11n hotspot, and a smart phone would join the hot spot and use a custom app to receive these streams in real time and mix them on the device. I'm hoping to achieve sub 15-20ms latency, but just don't know how feasible all of this will be. Hardware-wise, I was thinking for my initial proof of concept that a Teensy3 might serve as the core of the device, reading inputs from the ADC's via I2S and muxing them together and sending them to the WiFi SoC (thinking about a Broadcom BCM4718 possibly) as IP Multicast packets. Although with that BCM4718, I might be able to just use it as the core, as according to the product brief, it supports I2S.

I'd prefer to do this with uncompressed audio, but don't know how feasible that will be from a bandwidth standpoint. However, my research has shown that doing it with compressed codecs will introduce an undesirable level of latency. I was hoping to be able to avoid delving into a DSP, and unless I'm missing something I don't see that I would need it since I'm not really trying to do any operations on the audio data on the device itself. The smart phones would be handling that on the client side. But I don't know enough at this point to know if thats a key component or not.

Can anyone provide some insight into whether this is even possible? Right now its just a pipe dream, and it seems like the bandwidth and latency issues would be a beast to overcome.

 

[mlu]

What audio quality do you need ? Number of bits and bitrate for each channel?

Do you think 4 ADC's using I2S are needed or do you know a single 8 channel ADC that can send one I2S stream to the host (Teensy3)?

 

[PaulStoffregen]

The upcoming (not yet released) audio library is capable of receiving 16 bit stereo 44.1 kHz data with only a few percent of the CPU. The I2S port has a multi-word format, but I'm not sure which ADCs use it, if any. All I've seen use stereo only I2S. But I haven't studied very many, so perhaps there are others out there?

If you can find such an ADC, then you'd need to hack the I2S receive code to use that format and receive 4 channels instead of 2. I actually have an idea about that... best to chat in detail once the first alpha release of the library is published, probably sometime in December.

Muxing the 4 channels into 1 stream should be fairly easy.

The audio library works in 128 sample blocks, so unless you intentionally add delay, the latency is 2.9 ms.

One part of this I don't understand is how you'd send the combined stream to the Boardcom chip? 4 streams will require a channel with at least 2.8 Mbit/sec sustained bandwidth.

The SPI port is probably the most viable option, since it can run at 24 Mbit/sec and using the FIFO it's pretty easy to get over 12 Mbit/sec sustained. Serial1 might also be possible, but I've not tested it that fast. I do know at least 2 projects have used Serial1 at 921.6 kbits/sec. Using polling, either of these will consume most of Teensy3's CPU time at those speeds. Both support DMA, but so DMA-based code exists for either. Writing such code is quite tricky, but not impossible.

 

[digital11]

What audio quality do you need ? Number of bits and bitrate for each channel?

Do you think 4 ADC's using I2S are needed or do you know a single 8 channel ADC that can send one I2S stream to the host (Teensy3)?

My target right now is 44.1khz/16-bit.

The upcoming (not yet released) audio library is capable of receiving 16 bit stereo 44.1 kHz data with only a few percent of the CPU. The I2S port has a multi-word format, but I'm not sure which ADCs use it, if any. All I've seen use stereo only I2S. But I haven't studied very many, so perhaps there are others out there?

If you can find such an ADC, then you'd need to hack the I2S receive code to use that format and receive 4 channels instead of 2. I actually have an idea about that... best to chat in detail once the first alpha release of the library is published, probably sometime in December.

Muxing the 4 channels into 1 stream should be fairly easy.

The audio library works in 128 sample blocks, so unless you intentionally add delay, the latency is 2.9 ms.

One part of this I don't understand is how you'd send the combined stream to the Boardcom chip? 4 streams will require a channel with at least 2.8 Mbit/sec sustained bandwidth.

The SPI port is probably the most viable option, since it can run at 24 Mbit/sec and using the FIFO it's pretty easy to get over 12 Mbit/sec sustained. Serial1 might also be possible, but I've not tested it that fast. I do know at least 2 projects have used Serial1 at 921.6 kbits/sec. Using polling, either of these will consume most of Teensy3's CPU time at those speeds. Both support DMA, but so DMA-based code exists for either. Writing such code is quite tricky, but not impossible.

I've been very interested in seeing your audio library release. Definitely perked up when I heard about that.

Its looking like to really make this happen I'm going to have to use something like TI's DSPs that have McASP and chain multiple ADCs together on the input side, and then send it to the Teensy via the output side of the McASP, basically like TI's pro audio mixer console block diagram describes, without the DACs. Going the DSP route should then allow me to get the data into whatever format I'd need for the Teensy, but man is that gonna be a pain to learn.

Getting the data to the Broadcom is the biggest question mark in my head right now though. Getting an actual datasheet on that thing is going to take jumping through some hoops I suspect. If I could use SPI, that seems like it would be optimal and potentially enable me to get to my goal of 8 channels. Otherwise, might I have to actually get the data into actual ethernet packets first and have the Teensy act like a locally connected client on its switch?