Stream audio data from Arduino/Teensy to Teensy w/ audio shield

Status
Not open for further replies.

d33k

New member
I would like some guidance on how to go about using a Teensy 3.6 w/ audio shield acting as a DAC to receive & playback audio data from another Arduino or Teensy.
The transmitting MCU would be something like an Arduino Due which doesn't have native I2S support running a synthesis engine (simple saw/sine wave oscillator). It would stream its digital synthesized audio to the receiving Teensy 3.6 which is simply acting as a DAC; receives digital audio data and plays it back.

What would be the best way to achieve this? I2C or serial? Any suggestions on how to encode the audio from the Arduino synthesizer to be sent to the Teensy?
 
I would like some guidance on how to go about using a Teensy 3.6 w/ audio shield acting as a DAC to receive & playback audio data from another Arduino or Teensy.
The transmitting MCU would be something like an Arduino Due which doesn't have native I2S support running a synthesis engine (simple saw/sine wave oscillator). It would stream its digital synthesized audio to the receiving Teensy 3.6 which is simply acting as a DAC; receives digital audio data and plays it back.

What would be the best way to achieve this? I2C or serial? Any suggestions on how to encode the audio from the Arduino synthesizer to be sent to the Teensy?

?? Why don't you synthesize on the Teensy ? Adding a due which is much slower makes not that much sense..?
Best would be SPI.
 
?? Why don't you synthesize on the Teensy ? Adding a due which is much slower makes not that much sense..?
Best would be SPI.

Hi Paul, thanks for your quick response. Mainly would like to do this as a proof of concept, I realize Teensy is much much faster!

Any pointers on how to encode the data to be sent via SPI and reading and playing it on the Teensy?
 
16 Bit per channel, 44.117Hz
@d33k,

So, at that data rate (remember 16 bits each for Left & Right samples) your best choices are I2S or SPI. If you chose the former, you could sync the T3.6's audio sample rate to the source by making it an I2S slave. With SPI, I don't know. What are your plans for synchronization?
 
Last edited:
As long as you can assume a reliable connection - which is a absolute must anyway - no data-synchronization is necessary. SPI has a clock signal.
You just have to make sure that transmitter and receiver start with the same channel. E.g. after reset always the left one.
Or, you could add a "reset signal" - a pin that goes high to tell the next sample is for channel 0. It's needed only once before transmit-start.

Edit: There will be the problem, that one board is a little bit faster or slower sampling than the other. I think, this is what gfvalvo meant. So you might have to insert or delete a sample from time to time. If both samples-freqs are not too far away, you will not hear that. Or add another sync signal....
 
Last edited:
Edit: There will be the problem, that one board is a little bit faster or slower sampling than the other. I think, this is what gfvalvo meant.
Correct. I don't consider it a proper design unless all the sample rates are exactly frequency-synchronous. You also have an issue in that there's not a great deal of flexibility in setting the SPI data rate on most processors because the divider choices are limited. So, you may not be able to pick one that matches the audio sampling rate closely at all.

Thinking about it some more, here's what I'd do:

First, let the T3.6 be the timing master to set the sample rate. Connect its I2S LRCK signal to the slave device that's acting as the audio source (of course, LRCK must also connect to the Audio Shield). Since LRCK runs at Fs, the slave device should generate its audio samples at exactly that rate.

Next, because of the above-mentioned SPI frequency issues, you'll have to use FIFOs. The slave device should put its audio samples into a FIFO at the frequency of LRCK. Every update cycle of the Audio Library (~2.9 ms) the T3.6 (acting as SPI master) will pull 512 bytes (256 is sending mono) using a high-speed SPI transfer (say 20 MHz). Those samples will feed the Audio Library.

Since the FIFO is filled and emptied at exactly the same rate (on average), everything will be synchronous.
 
No need for that. The SPI-Slave automatically uses the Master's clockrate. The master hast just to be fast enough.
Yes, but the Master may not be able to pick a rate that's close either. Like I said, divider choices are limited. That's solved the synchronization / FIFO technique I proposed. With a FIFO the read and write rates only need to be exactly the same on average.
 
The audio-library AudioPlayQueue will be helpful.
Yup, once the master pulls the samples from the slave via SPI (every ~2.9 ms), it shoves them into an AudioPlayQueue. That is the FIFO on the master's end, allowing the samples to be sent to the Audio Shield at exactly the same Fs at which they were gathered. Like I said, it's not a proper design unless everything is synchronous (IMHO).
 
Status
Not open for further replies.
Back
Top