Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

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

  1. #1
    Junior Member
    Join Date
    Feb 2020
    Posts
    2

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

    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?

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    Quote Originally Posted by d33k View Post
    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.

  3. #3
    Junior Member
    Join Date
    Feb 2020
    Posts
    2
    Quote Originally Posted by Frank B View Post
    ?? 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?

  4. #4
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    16 Bit per channel, 44.117Hz

  5. #5
    Senior Member
    Join Date
    Feb 2017
    Posts
    368
    Quote Originally Posted by Frank B View Post
    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 by gfvalvo; 02-15-2020 at 12:37 AM.

  6. #6
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    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 by Frank B; 02-15-2020 at 08:36 AM.

  7. #7
    Senior Member
    Join Date
    Feb 2017
    Posts
    368
    Quote Originally Posted by Frank B View Post
    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.

  8. #8
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    Quote Originally Posted by gfvalvo View Post
    So, you may not be able to pick one that matches the audio sampling rate closely at all.
    No need for that. The SPI-Slave automatically uses the Master's clockrate. The master has just to be fast enough.

  9. #9
    Senior Member
    Join Date
    Feb 2017
    Posts
    368
    Quote Originally Posted by Frank B View Post
    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.

  10. #10
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    The audio-library AudioPlayQueue will be helpful.

  11. #11
    Senior Member
    Join Date
    Feb 2017
    Posts
    368
    Quote Originally Posted by Frank B View Post
    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).

  12. #12
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,557
    Yes, the idea to use LRCK is good.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •