Can I access the audio board's ADC output directly?

Status
Not open for further replies.
MrTom

MrTom

Well-known member
I'd like to mess with accessing the audio data directly. I'm currently using the FFT with the audio board to split it into frequencies.
But how can I also access the ADC data directly to make a sort of Oscilloscope to see the waveform?

Thanks.
 
PaulStoffregen said:
The queue objects give you access to the raw audio data.

http://www.pjrc.com/teensy/gui/?info=AudioRecordQueue
http://www.pjrc.com/teensy/gui/?info=AudioPlayQueue
Click to expand...

I'm getting a massive delay in the audio queue buffer and I don't even have any delays active. With the code below I get about a 500ms delay of the visuals compared to the actual audio going through. When I comment out tft.fillWindow the delay gets a lot better, but there's still about a 50-100ms delay from what you hear to what you see on the LCD. I get way better response times while using fft1024, like real-time access no matter what other functions I use.

Is there something else I should be doing? Or is it not possible to have access to raw audio as fast as FFT does?

Code: 
#include <Audio.h>
#include <RA8875.h>

AudioInputI2S            AudioIn;
AudioOutputI2S           AudioOut;
AudioMixer4              AudioMixer;
AudioRecordQueue         AudioStream;
AudioConnection          patchCord1(AudioIn, 0, AudioMixer, 0);
AudioConnection          patchCord2(AudioIn, 1, AudioMixer, 1);
AudioConnection          patchCord3(AudioIn, 0, AudioOut, 0);
AudioConnection          patchCord4(AudioIn, 1, AudioOut, 1);
AudioConnection          patchCord6(AudioMixer, AudioStream);
AudioControlSGTL5000     audioShield;

RA8875 tft = RA8875(20, 2, 7, 14, 8);

void setup() {
  tft.begin(RA8875_800x480);

  AudioMemory(50);

  audioShield.enable();
  audioShield.inputSelect(AUDIO_INPUT_LINEIN);
  AudioStream.begin();
}

void loop() {
  int16_t x, y, mybuffer[128];

  if (AudioStream.available() >= 1) {
    memcpy(mybuffer, AudioStream.readBuffer(), 256);
    AudioStream.freeBuffer();

    tft.fillWindow(RA8875_BLACK);
    for (x=0; x<128; ++x) {
      y = map(mybuffer[x], -32768, 32767, 0, tft.height()-1);
      tft.drawPixel(x,y, RA8875_WHITE);
    }
  }
}
 
FrankB had on screen bars on the 320x240 tft last year, not sure if bing or Google can find that? It seemed like it was real time to music.

It seems like be posted his code I didn't get to look at yet. If you find his tetris in his posts, I think it was before that.
 
defragster said:
FrankB had on screen bars on the 320x240 tft last year, not sure if bing or Google can find that? It seemed like it was real time to music.

It seems like be posted his code I didn't get to look at yet. If you find his tetris in his posts, I think it was before that.
Click to expand...

I found if I limit the for loop to just 32 and only drawing 32 samples then it's pretty much real time. I think 128+ samples is just too much data to draw on the screen for real-time. 32 samples spanned across 800 width is going to look mighty pixelated.

EDIT: Even drawing non-filled rectangles with a width of 10 for 32 samples has a ~100ms delay.
EDIT2: Hmm, adding a AudioStream.clear() at the end of my graphics drawing function seems to have helped a lot. It seems to be more responsive. I think during the time it takes to draw all the graphics the audio buffer is still piling up with data and somehow this adds a delay to everything. It seems discarding the audio data that accumulated during graphics drawing seems to speed things up and make it real-time.
 
Last edited:
It doesn't seem to matter where I put the AudioStream.clear() function, just as long as it's called. It's the same even if I put it before the graphics functions, right after the freeBuffer().

I've changed some of the graphics code, but as it is now after a screen update there's about 10 packets of audio available to read. Those packets accumulate from 9, 17, 25, 34, 42, 50, to the maximum 52 which from the info is about 150ms of audio. So I guess a buffer dump is necessary at some point to keep the buffer from overflowing.
 
Status
Not open for further replies.
Back
Top