I have a biometric sketch running on a Teensy 4.1. I am experiencing intermittent audio stutters in wave file playback from the onboard SD card. Obviously, I should make a simpler sketch to isolate the problem, share that, and perhaps someone could try duplicating the issue. I am working on that! But in the meantime I thought I would reach out here for an initial sanity check.

Using the processorUsage calls to the audio library, I see that the average cpu usage is about 8%, and average memory usage about 15. When I start SD playback, the average jumps up to 38%. Iím playing a single stereo 16bit wav file, itís 15 minutes long. When the audible stuttering happens, the wavplayer processorMaxUsage jumps to over 100%. The stuttering doesnít always happen at the same point in the playback.

I understand that the SD card type, formatting, and potential file fragmentation is a likely culprit. I have tried several class 10 cards and several formatting procedures. I have some new cards arriving today for further testing. Iíve read various posts on this forum about this and am
somewhat hopeful that the new cards will help.

In the meantime, hereís my first sanity check question. Is 25% cpu ďtypicalĒ for a class10 SHDC in the T4.1 onboard card slot? (It surprised me, given that the rest of the code only shows 14% max total cpu, yet has about thirty filters and 8 mixers and some custom envelope followers, and a lot of stuff based on Chip Audetteís float32 audio lib. (All that code has been running extremely well for many months, btw! T4 is an amazing platform.)).

And my second sanity check question is, is the object-specific processor usage a pretty reliable diagnostic, that the problem is
isolated to the SD card read updates? Or could other code be interrupting the SD reads? Iíve only got one other interrupt running in my sketch, for a 4D display, and Iíve tried disabling it.

Again I appreciate that itís difficult to give any useful advice without seeing my code, and Iím working to make a simpler test case for that.

Earlier versions of this project played just fine for hours on end. Since then I have added quite a bit of hardware and software, including a data logger that collects data to RAM during audio playback, then waits for the audio playback to end, then writes the log array to a small text file to the SD card. Iíve been meticulous to retrieve the log files, reformat the card, and immediately recopy the audio file to it so it stays contiguous. Hard to imagine that process is fragmenting the audio file...

Any suggestions or red flags come to mind? Thanks!