microSD Cards for Audio 2024
I’ve previously written several articles about the unique requirements placed on microSD cards when they’re used in Robertsonics polyphonic, low-latency players such as the WAV Trigger and Tsunami. Modern microSD cards and their internal flash controller firmware are designed to maximize large file transfer (read and write) speeds, and are not necessarily concerned with the access time for any single read or write operation. If a couple of reads out of millions take 20 or more milliseconds for housekeeping, who would notice? Well, we do.
Robertsonics audio players are both polyphonic (playing multiple audio files simultaneously) and low latency (typically 5ms from a trigger or MIDI event to the onset of sound) and require that no single read operation take longer than around 23ms. If that should occur then there will be an audible glitch. This may sound like an unreasonable requirement, but in past articles, I’ve documented that modern microSD cards typically take significantly less than 1ms to complete a block read.
Digital output brackets a 4-sector block microSD read while Tsunami (mono) plays a single file. Read operations are about 400us every 23.2ms. Card is a Delkin 32GB V10.
In developing the firmware for both the WAV Trigger and Tsunami, I’ve tested for audio glitching at max polyphony, and most of the microSD cards that I’ve used have had no issue keeping up. Of course, I‘ve also encountered some that don’t work well at all, but I’ve found these to be in the minority.
Occasionally I hear from customers who are experiencing audio glitching with their Robertsonics player. Recently, two different customers sent me both their players along with the cards they were using for me to evaluate. In both cases, they were using the SP 3D NAND 32GB card that I had previously declared to be good. I’ve now spent several days examining and testing these cards and will use this post to document my findings. If you’re not interested in all the detail, you can skip to the end for the conclusions.
I was able to quickly reproduce glitching with both cards that the customers sent me simply by listening. The issue was not with their hardware, because their cards glitched in my players, and their players did not glitch with my cards. Luckily, one customer supplied their card with a mono sine wave file. Playing the file from that card, I captured the audio output of a glitch and could see it clearly in Adobe Audition.
An audible glitch playing a sine wave from an SP 3D NAND 32GB card on a Tsunami with mono firmware.
A couple observations: 1) The glitch is caused by a section of the wave form that has been replaced with out-of-phase data from the same sine wave. It’s not random noise, and it’s not silence. 2) The length of the section is about 695 samples, which is less than a single block read of 1024 samples. These symptoms are precisely what would happen if a block read operation took longer than 23.2ms and the read buffer was starved.
To prove that this was indeed what was happening, I instrumented the Tsunami mono firmware to bracket the block reads with turning on and off the debug digital output pin, so that the duration of the resulting pulse indicates how long the read takes. I programmed my oscilloscope to trigger only on a positive pulse longer than 23.2ms and was able to capture the following trace, coincident with an audio glitch. Recall that it ought to look like the first trace capture above.
This trace race shows 4 block read operations taking far too long, with the third one taking longer than 23ms. It recovers and the last two reads are normal.
As some of you may know, I’ve written special firmware for the WAV Trigger to perform block read timing tests as a way to measure card performance. I recently completed a version of this same test firmware for Tsunami and was anxious to try out both versions on these now-known-to-be “bad” cards. You can imagine my surprise with both cards tested perfectly with both versions of my test firmware. Clearly, my testing strategy was missing something important.
My original test firmware performs one million block reads over the entire microSD card, using a random number generator to provide the starting sector for each operation. A formatted 32GB card has over 60 million sectors, whereas 10 minutes of audio uses only about 103,000 sectors, 0.2% of the available sectors, all concentrated at the beginning of the microSD card. I realize now that my test program was spending all it’s time testing sectors that had never been used, rather than the sectors that actually contained audio.
So I rewrote the test program to test all the sectors used by all the .wav files on the microSD card, and only those sectors. Effectively, it fast-forwards through all the .wave files and measures each block read operation. Using the same pulse-bracketing method as before, here’s what running the test should look like with a good card.
Tsunami mono test firmware fast forwarding through the .wav files, performing block reads every 2ms, with a “good” Delkin V10 32GB card.
The corresponding test results for this Delkincard confirm that this card does not glitch:
Results of the new testing firmware on a Delkin V10 32GB card after 4 iterations.
However, when I run my new testing firmware with one of the customer’s “bad” SP 3D NAND cards, I get the following result after 4 iterations.
Poor test results from a customer’s SP 3D NAND 32GB card that produces audible glitches. At least one block read was almost 40ms.
Now there’s no way to know if the customer’s cards were “bad” before audio files were written to them, but I suspect they would have tested “good” when new. If so, then the conclusion is that for some reason, the customer writing files to the card caused some sectors either to go bad, or be identified as bad by the internal flash controller. Perhaps inferior cards do not handle bad sector mapping/substitution as well as others. These are just guesses. There’s really no way to know what the flash controller firmware is doing.
Conclusion
I remain confident that when a customer experiences audio glitching with a Robertsonics player, the culprit will be the microSD card taking too long to respond to a block read. All of my testing confirms this. How to predict which cards will perform well and which cards will perform poorly, however, I do not know. I do believe that my new Tsunami testing firmware will correctly identify “bad” cards, but whether a card is bad out of the box, or becomes bad after writing audio files to it, I’m not yet sure. More testing is required.
I still have SP 3D NAND 32GB cards that continue to be stellar performers, but two customers have now sent me proof that some do not work well at all. Whether this is because the brand does not have good quality control or something unusual was done to those two cards, I can’t tell.
I will continue to use my new test on other cards, including some of the “industrial” grade cards that I have, and will post any significant findings.
Below are links to the new Tsunami test firmware. Because it actually simulates playing .wav files, you need to match the firmware to the files, i.e. stereo or mono, so there are two versions. The more .wav files on the card, the more sectors will be tested. You install the test program the same way you install Tsunami firmware - rename the hex file to “tsunamix.hex” and initiate the bootloader. Connect Tsunami’s serial control port to a terminal emulator at 57.6k baud (8-bit, 1-start, 1-stop, no parity.) Remember to press Tsunami’s reset button each time you change the microSD card.
There is not yet a WAV Trigger version of this test. Stay tuned…
