Issues with NXP MCUXpresso SDK DMA library

[RoryHand]

I have been struggling away for a good number of months now, with a polyphonic audio project using a microcontroller.  (This was originally all done on an mbed but I had to switch over, for reasons given below).  It consists of reading .wav files off of a micro sd-card, and then being able to output these to a wolfson audio codec via I2S. 

A few requirements:

 - There must be enough memory to open have up to 25 different .wav files open at once, so I can immediately switch or overlay any given sound immediately (this was my reason for moving over from mbed; there is an actual file limit somewhere that I could not change, and my estimates showed that there potentially wasn't enough memory on an LPC1768 board).

 - I need to be able to play up to 6 .wav files at once.

 - Sample rate and bit depth - 16 bit is ideal, as for sample rate, I can live with 11025Hz as it sounds fairly good.  However anything less than this sounds terrible and so is not an option. 

I have moved everything over to using the LPC55S69 EVK, part of the LPC5500 line from NXP which I gather is fairly new.

However I am running into some problems.

Despite the fact that on the mbed, I had enough latency to play 6 or 7 different 11025Hz sound files at once, I cannot do this on the LPC55S69. if I try to do this, the sound starts lagging and popping due to there not being enough time to read the .wav samples and add them together before the DMA triggers an interrupt.  This is odd as the mbed lpc1768 can run up to 96MHz whereas my current LPC55S69 I am running the core at 150MHz.  Moreover the sd card libraries appear to be using SDIO and, presumably, 4 bit SDIO, so the read times from the sd card should be pretty fast.

I have been using all of the MCUXpresso SDK APIs/libraries for this, including the I2S/DMA side of things.  Looking at the files for this, there seems to be bazillions of different functions that get run once an interrupt is triggered, before the next transaction is even started, and before it finally comes back into the main code. I barely understand what half of them are even doing.  (And of course, there is little to no documentation for any of these).

My (very) basic understanding of DMA was that it works nicely in the background to transfer data from your specified memory or peripheral location, and once all of this has been transferred, it interrupts, you tell it to start again, and off it goes.   But it would appear that NXP's API is doing tons more than this. 

The long and short of it is I have already been reading carefully through the "user manual" for this chip in the DMA and I2S sections and am wondering if it may be better to write this all from scratch.  Although, the manual isn't incredibly clear about some things, however.

If anybody has any experience of using DMA and/or I2S on this range of processors, or just general advice,  please let me know, I can provide more details as I go along. 

[Jay1011]

I'm presently working on something similar.  I'm using an STM32 board to play WAV files from local storage -- a NOR flash in my case -- via I2S to a local speaker.  I'm not trying to play 6 WAV files at once, though I'm using a 32KHz sample rate rather than 11025 Hz.

The key performance issue I ran into is that you have to use DMA for both "sides" of the transfer: from NOR flash (SD card in your case) to memory *and* from memory to the I2S output.

The problem I ran into is that whereas the memory to I2S transfers were 100% under my control (i.e., my code) and thus I could use DMA for them, the NOR flash reads were 100% out of my control (using a canned filesystem library) and they were not using DMA.

The result was that the CPU sat there babysitting the NOR flash read and was unavailable to deal with the other things that needed to occur to insure a timely arrival of the WAV samples to the I2S unit.

I ended up recoding a portion of the "file read" code in the NOR flash library to use DMA-based transfers, and this has solved the issue for me,

I have no idea if your problem stems from a similar cause, but it may be worth a check.

[RoryHand]

I will have a look into that Jay1011, thanks for the pointer.  I would be surprised if that was the issue as I dont believe the original application I had running fine previously on an MBED was using DMA for the sd card reads...but I could easily be wrong, as its almost impossible to understand what the hell is going on lower-level with MBED.