Cant find the logical error on DUE digital sampler

Official Hardware Mega Due
1

Hello. I've been working on a digital sampler using the Arduino DUE. The idea is to use an array of 10000 samples which is populated from an SD card. The file on the SD card is built up from a sample from the ADC approx. every 33uS. I need the sampler to be able to switch between several states: forward playback, reverse playback and an adjustable slow playback.

My idea was to make a sort of granular sampler which will load the 10000 samples and then you can either play through at normal speed or just loop it until you want to load the next 10000, etc.

I am seeing a strange problem, however. When feeding it a 1kHz ramp wave, (I have the sampler starting up in normal forward playback,) I should get the 1KHz wave back on the DAC but instead it plays back at the correct speed for a brief second and then it plays back the wave but at about 17 Hz. This is way slower than it should be. Then it plays at 1kHz for a few seconds every 16 seconds. It toggles between the 2 frequencies like this forever.

Here is the code. (Had to do an attachment because it's too long)

Sorry it's a bit messy but I've been trying a lot of different stuff and haven't gotten around to cleaning it up yet. (not all the variables in the beginning are used, etc...) Been banging my head against a brick wall here trying to troubleshoot this thing for a about a week now. :stuck_out_tongue_closed_eyes: Hopefully someone can give me some insight as to what I'm doing wrong.

Thanks.

Digital_Sampler_2-1-15_RevM.ino (17.2 KB)

2

Without looking at the code my immediate theory is you are limited by the SDcard
access over SPI which isn't exactly speedy.

3

Hi MarkT. Actually I've ruled out the SD card. Slowing down the interrupt by 10x still yields the same result. Anyway I don't think the frequency of the playback is dependent on the TC interrupt or the SD card failing to retrieve data.

The SD card is only accessed to save a couple bytes at a time. Also, the file gets written over on start up so it cant be old data from previous tests.

And I removed the Serial.print() stuff too just to eliminate that variable.

But I assume that the serial stuff only runs when the serial window is open? Does anyone know? That could be slowing down my code I guess.

4

The Due implementation of Serial is very bad. Don't use it anywhere near your timing-critical functions. It is capable of sending one character with no impact on your program but the second character halts your entire program waiting for the serial buffer to be sent.

5

Interesting.

Does serial slow things down just by being implemented? (Serial.begin())

What I mean is, if I'm only calling serial during setup, (check registers etc) does it still slow things down?

6

No, Serial.begin() doesn't slow anything down.

7

OK. So I stand corrected.

The problem was with the SD card as MarkT suggested. I did a few quick time tests and it turns out that the class 4 SD card I had was actually faster than the Class 10 (by a lot!)

I got the class 10 because I thought it would be faster but to save 2 bytes to the class 4 takes around 12uS while the class 10 was taking about 1.6 mS!

Since the original post, I have also revised the code several times. My plan is to have the SD card load the buffer all at once. According to my time tests, this will take roughly 106 mS max.

I have 2 buffers: incomingBuffer is for the audio samples from the ADC before they get saved to the SD card, and playbackBuffer gets loaded from the SD card file and holds samples to be played on the DAC.

There is an interrupt every 25uS to sample the ADC and do several other logical operations but this should not affect the SD card as the SPI is not used for any of the operations in the interrupt. The SD card should pick up where it left off after the interrupt is over.

I am treating the playbackBuffer as if it is 3 separate buffers each of 10000 samples (20000 bytes). This is to give the SD card plenty of time to load the next buffer before it needs to get sent to the DAC.

In forward playback, the next buffer should load while the current one is playing. In case I want to switch playback direction, the previous buffer is still saved and can be played t will.

Directly after power up, the sample from the ADC gets sent directly to the DAC until enough time has passed to build up the SD card file. The problem I am seeing is that the output cuts out after the initial buffer data is used up. (about 1/2 second or so.)

I am still having trouble finding the error in my code and have spent a lot of time trying to troubleshoot but have gotten nowhere and I'm getting very burned out.

If anyone can help me find where I'm going wrong it would be greatly appreciated. Thanks.

Digital_Sampler_2-1-15_RevP.ino (23.1 KB)

8

Just an update. I tried to troubleshoot this as well as I could last night but still getting nowhere. I will continue working on it.

If anyone could take a peek at the code I just posted I would appreciate it. Thanks again.