PDA

View Full Version : Can I access the audio board's ADC output directly?



MrTom
03-10-2016, 07:20 AM
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
03-10-2016, 08:32 AM
I'd like to mess with accessing the audio data directly.

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

MrTom
03-11-2016, 05:49 AM
The queue objects give you access to the raw audio data.

Nice. So much fun with these little things. Thanks.

MrTom
03-13-2016, 09:36 AM
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

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?


#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);
}
}
}

defragster
03-13-2016, 09:51 AM
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.

MrTom
03-13-2016, 11:19 AM
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.

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.

MrTom
03-14-2016, 07:50 AM
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.