Save file to SD in a different thread (or use interrupts for sampling?)?

Status
Not open for further replies.

qcarver

Member
Hello,

I see a lot about playing quad-audio with the sparkfun teensy quad-audio solution, but not much on recording quadio (quad-audio?).

Using polling, it doesn't seem possible to record audio with out "glitches".

I think the issue is probably the length of time it takes to write to the ("Ultra Plus") SD card. You just can't get back to the audio queue fast enough to get a continuous sample.

My question is: Can writing to the SD disk be spawned in a separate task (thread/process)? Or alternatively can the loop() focus on writing to SD only to interrupted by SD sampling? In the latter case maybe interrupt every 5800/2 mics and check?

(Source code in link to forum thread above) or here

Thanks,
QC
 
You unfortunately don't specify which Teensy you use and which SD card controller, thus it's difficult to give good advice. Using the "on board" SDIO controller of the Teensy 3.6 is one thing, using one of the SD controllers on the two audio shields is a different thing.

When using an SD controller on an audio shield, the data transfer is done via SPI. If your amount of recording data can not always wait for the SD card lately, you should create a buffer in RAM, big enough to hold enough samples for the worst latency case and empty that buffer towards the SD card using the new DMA SPI library which can do that in the background almost without stealing CPU cycles. Most probably, the Teensy 3.2's RAM will not be sufficient and you'll have to use a Teensy 3.5 or 3.6.
 
For what it's worth, I once faced a similar problem with a datalogging application. I investigated the possibility of putting SD write access in another thread, but abandoned the idea because of non-deterministic latency on the part of the SD card. When the SD card is shuffling blocks around internally, the write operation can take up to 1s instead of the normal +/- 80ms. Because my application could be expected to read some stuff from the SD at random times, I would have to implement signalling between threads :rolleyes: .

There are ways to drastically reduce write latency by using pre-allocated files though.
 
You unfortunately don't specify which Teensy you use and which SD card controller, thus it's difficult to give good advice.
The article referenced states: "You’ll need the following parts – a Teensy 3.2, two Audio Adapter boards, and some male and female headers.". The previous post, linked-in above, states: "I've got a teensy 3.2 driving 2 audio" ... to be clear friend, it is a Teensy 3.2 ;)

SD card using the new DMA SPI library which can do that in the background almost without stealing CPU cycles
I am using AudioRecordQueue's provided as per the online WYSIWYG to buffer the audio. This part seems fast enough. Time is lost in the WRITING to the SD card. Do you mean that you can use DMA SPI to write directly to the SD card? That would be very exciting. Please let me know if you know that it is an option.

-Thx
QC
 
For what it's worth... Because my application could be expected to read some stuff from the SD at random times, I would have to implement signalling between threads :rolleyes: ...There are ways to drastically reduce write latency by using pre-allocated files though.

Thanks, I took a look at your SDLLL (templates! nice) and then pulled down SdFat to try a build. Then I noticed it's not really for the 3.2 (__MKL26Z64__) but for 3.5's and 3.6's (__MK64FX512__ __MK66FX1M0__) architecture. Some key defines get ndef'd, which makes sense, looking at the pins doing sdio with a shield on 3.2 it's totally different than on a 3.6. Furthermore I see the MichaelMeissner even said "The Teensy SD.h implementation includes its own version of SdFat library". So perhaps there would be no performance gain using the SdFat anyway. SD so far has worked fine -- I was just hoping for something "faster".

So, taking lessons learned from the rest of your comments. (1) It sounds like I'll get somewhere between 25% and 400% improvement just by making my files ahead of time and stuffing them with zeros? Then overwrite them later. I'm sure I can at least implement that w/o much trouble. Did I get that right? (2) Further, about the threads thing. I can set an ISR or something to write out every minute, I don't have to do anything else. Right now I'm using rotating files about a minute long each. Would threads help in this situation? Do you have any examples or favorite libraries for this?

Thanks for your feedback, there was lots of good stuff there.
QC
 
Status
Not open for further replies.
Back
Top