Audio coprocessor - play sound while CPU do something else

Hi,

I'm designing a custom board for a project and I would like to add audio effect triggering in the program. But I don't want the main CPU (Arduino zero) to have to play the sound itself, only send a command to a coprocessor that will play the sound while the Zero do something else.

My Zero is connected to a SD card and will need to access it regularly, so the coprocesor must have its own flash memory (SPI flash for example). At power up, the Zero could copy sounds from SD card to SPI flash memory via the coprocessor (unable to share an SPI peripheral with two master => Zero can't access the SPI flash directly).

Then, when the Zero send a command (SPI / Serial / I2C, any of this could work) to the coprocessor, with a number, the coprocessor plays the specific numbered files.

I would like something easil integrated on custom PCB. I've found WT588D chip, but they don't seem to be available at Mouser nor Digikey as raw chip, and the whole module is not integrable on small PCB.

Basically what I need is a system capable of playing sound commanded by the Arduino Zero, that should be easily integrated on custom PCB (smd chip, available or simple schematics) and that use a SPI flash chip, loaded from SD card by the Zero before start.

If you have any other idea, I would be glad to know! :slight_smile:

But I don't want the main CPU (Arduino zero) to have to play the sound itself, only send a command to a coprocessor that will play the sound while the Zero do something else.

I'm petty sure that's how most [u]Audio Shields[/u] work. You just send a command to start/stop playback or to select a file to play. They have their own DAC, clock, and storage for the sound file (and some other logic).

Yes I've found the VS1053B decoder, but I thought there is a special firmware in it, that prevent anyone to copy the design. Also, I don't need mp3/aac/recording function. For me, playing raw binary file that have to be processed before is OK : I need a short response time and mp3 decoding takes too long I guess. By the way, this use an SD card and in my design the coprocessor won't be able to access the SD card for playing sound, only at startup, for copying them to a flash storage chip...

I was thinking about using a Atmega328p with the PCM lib, but again this only use SD card and I will need to modify the code to read sound from a flash chip. I will also have to program the files copying process from SD to flash.

That's why I was looking for a device that may already exists.

Thanks for your answer though :slight_smile:

for copying them to a flash storage chip...

The architecture of the Arduino processors does not allow copying into the internal flash.
I think your design is unfeasible using Arduinos.

Try one of these modules - I've found them to be pretty responsive to serial commands.
And if not quick enough, you're not out much cash and you have it for a future project.

Alternative is to read .wav data (same format as a CD) from an SD card in 512 block bytes and play it back thru your own DAC. A 328P can do that after receiving a command from your Due.
fat16lib wrote some code to do that in this thread for some hardware I was developing (and still want to get around to finishing)
http://forum.arduino.cc/index.php?topic=180769.0

@Grumpy_Mike, I want the arduino Zero to read audio data from SD card, send it via I2C to 328p, and 328p write those data to SPI flash, not internal program flash. Even if the 328p is able to rewrites its own flash, I will need this space to build a correct I2C interface.

@CrossRoads, I want a module that don't use an SD Card, because my main application running on the Arduino Zero should be accessing the SD card while the audio is playing. I don't want to have 2 SD card either. That's why I want a coprocessor. The Zero is able to play .wav file from SD card and has already a DAC, but I need all its processing power for other things :slight_smile:

Finally, I need the system to be redoable on my own custom PCB, to gain space, and the mp3 module is not...

Don't you think that the 328p + SPI flash as I2C peripheral is a good combo?

Can't the coprocessor have it's own SD/uSD card?

Having the Due send the coprocessor data to write to external SPI is fine too. Lot of SPI FRAM chips out there, they have EEPROM non-volatility but with SRAM access speeds. Look for FRAM Memory at digikey & mouser.

I want the arduino Zero to read audio data from SD card, send it via I2C to 328p, and 328p write those data to SPI flash, not internal program flash.

Would have been good to say that from the start.

I2C is quite slow when it comes to moving large chunks of memory about. The default speed is 100K bits / second which gives you just under 10K bytes / second.

I am not quite sure what your question is. Do you want to buy such a system or do you want to make it?

At the beginning I wanted something already existing, but it seems that there are not a lot a solutions others than SD card player and things like that. In my second post I talk about the possibility of using a 328p as coprocessor with an SPI flash as storage.

The coprocessor can't have it's own SD card.

I was planning to use I2C to send the audio data only once, after boot. Once the audio data is copied from SD to SPI flash through arduino Zero and then 328p, the I2C communication will only be used to send one byte is a number for example that indicate to the 328p which track to play. That why the speed of I2C is not a big problem if I go for this application.

I need to make 10 or even more devices which is based on the SAMD21G, the arduino Zero MCU. I would like to find a way to add sound effects without occupying the cpu processing powwer to much. If something exists, that is able to act like this, I would be glad, but it needs to be a chip I can buy and solder myself on the PCB. Not a full module, unless the schematics (and eventually the firmware) are open source and component easily available.

Sorry for my unclear explanation... Here is a schematic :

Sound effects a lot of storage space. If storing in SPI FRAM/SRAM/EEPROM, that equates to a lot of chips, depending on the duration of the effect and the sample rate used. One second at mono CD quality rate is 88,200 bytes. That's why SD cards keep being suggested. How much data are you planning on moving around? I would use SPI to send to the 328P at 4MHz rate, vs 100/400KHz of I2C.

With a SPI flash of 2Mbytes I should be able to store 1minutes of 8bit mono sound at 32KHz sample rate. I should also be able to lower down to 16KHz sample rate, and SPI flash up to 16Mbytes are not to expensive.
I don't plan to play long music files, only short sound effects.
SPI is indeed faster, but I think it's a bit harder to implement into an Arduino as a slave, no?

I've put a huge amount of work in the Teensy audio library so you don't need to use a coprocessor for these sorts of projects. It does require stepping up to the Freescale K20 (better DMA and faster CPU), but the price isn't very different from Atmel SAMD20. Arduino compatibility is also very good. With the higher performance hardware and audio library, you can easily play sounds and do lots of other audio stuff. The audio interrupt runs every 2.9 ms, using some CPU time, so it's not entirely without a CPU impact, but most normal Arduino programming works very well with this CPU sharing model.

To give you an idea of how well it works, take a look at the Hackaday Supercon badge hacking winner from last weekend. His spectrum analyzer badge was FFT analyzing live audio from a mic, while managing to update a TFT over SPI bus. It also had modes where it could play an uncompressed WAV file from the SD card (reading over the SPI bus), and compute the FFTs, and draw to the TFT (also on the SPI bus). No coprocessors required!

I also have a work-in-progress rewrite of the Arduino SD library, intended to really boost performance for these sorts of projects. Currently, the optimized version can only read the card but not write. It uses the multi-sector cache and is interrupt safe, so you can access the card from your non-interrupt Arduino sketch while the audio library also accesses it from within interrupts.

If you're absolutely committed to the SAMD20 and a coprocessor chip, then so be it. But if you're willing to consider alternatives, I think you'll really benefit from giving this all-on-the-same-chip approach a try.

Hi Paul, thanks for your answer. I have already a teensy 3.1 and have experienced a bit with your AMAZING audio library and tool! I have to stay with a samd21. I tried to modify the existing audioZero library to be non blocking, but I didn't achieve it. I will continue though.
I doubt I have enough skills to develop an efficient interrupt based audio playback system. That's why I wanted to find something already existing that could be easily integrated in my current design.
Anyway, your work on the teensy audio lib is really awesome.

Why are you stuck with the SAMD chip?

My design is a stack of 2 pcb, and I already have the main board with the samd21. The audio part should be on the second pcb.
The main board is very costly to produce and I don't wan't to design and buy a new one. The second one is much cheaper. I would like to implement the audio things on this second PCB. At the moment I have tried to route the DAC pin to the second PCB, that include a LM386 based amplification system, with SMD speaker and audio jack. The audio quality is quite bad though, because of a 15v switch regulator that is not powerfull enough and produce noise on the DAC line.
This issue with the fact that the AudioZero lib is blocking, made me think of using a coprocessor.

If you write your own code it would not be blocking.
I have just written non blocking code on the Uno for outputting samples it takes up very little CPU time.

Hi,

I have a pseudo working library for audio playback, not blocking.

It plays mono 8bit wav files at a sample rate of 22.050KHz. At 44.100KHz, my ISR is to slow.

It plays mono 8bit wav files at a sample rate of 22050KHz

I bet it doesn't.
Who has a sample rate of just over 22MHz?

Yes, sorry, I mean 22050Hz and 44100Hz, not KHz :smiley:
I edited the post.