I am building what could best be called a monitoring system. It reads a few sensor inputs and saves information. It also drives a display with current information. What I want to add could be called "a horn". I want to play short (1-4 second) audio segments. Not high fidelity (I figure 3KHz bandwidth is sufficient) and they won't be changed so the process of converting the sound to a usable file doesn't need to be "easy".
I have looked at assorted code and could just play but am open to suggestions. I realize that to get 3KHz bandwidth I am going to need interrupts at at least 6KHz. I figure if dealing with them only uses 50% of the processor (mega2560) I will be OK.
The simplest way is to use the tone function:-
http://arduino.cc/en/Reference/Tone
Does it have to be a complex waveform?
I hacked a sound module, the types where you press a button and get a sound effect in this project:-
http://www.thebox.myzen.co.uk/Hardware/Crazy_Golf.html
The other way is to set the PWM frequency to something like 30KHz and feed samples to a PWM pin. With a bit of filtering you get something that should fit your project. The snag is where are you going to store your waveform?
Thanks for your reply. The idea of using a "sound chip" like you did is another interesting possibility.
What I did last night (after posting my question) was play with speaker_pcm. It actually does what I need but I am worried about how much CPU will be left after I deal with the interrupts for driving the PWM pin. The sounds are not exotic/hi fi. For example, I have a train whistle sound which will be one choice. It is only about two seconds long. I lowered the sample rate (interrupt rate) to 6KHz and it still sounds fine. That means only 12000 bytes for the sound sample.
The other tasks are pretty much logging and display update.
Let me explain what this is for. We want to put these units in electric TukTuks (little 3-wheel vehicles) and electric scooters. There will be a display to let the driver know battery status plus we want to log battery state (voltage and current) and distance. The log will most likely be written to an SD card.
My concern right now is whether I will have issues with the SD write with the "horn" interrupts. But, as I write this, one obvious solution is to disable the horn while doing the write. The human is not going to notice the delay.
My concern right now is whether I will have issues with the SD write with the "horn" interrupts.
I would not have thought so.
That means only 12000 bytes for the sound sample.
That is still a lot of memory for a machine with only 2K of memory. I am assuming you are storing the 12K in program memory, are you retrieving it quickly enough?
The idea of using a "sound chip" like you did is another interesting possibility.
There are several boxes of the same type with different sounds in them and they do interface directly to a 5V system.