I am trying to use the analog wave library to output sound from an array, and while it works, I can only use a very tiny waveform on the Arduino Uno r4, as it has very little memory. What I want to do is be able to instead put the array of buffers/samples into an SD card, and then be able to read from that array as if it was an array on the built in memory on the Arduino. I am aware of the df player mini and the likes, but I want to be able to dynamically change the frequency of the sound, and I'm not sure if I can do that as easily on the df player.
I'm sure. You can't do that at all on the DFplayer mini.
Taking what you wrote literally, no, you can't. You can read data in from the SD card to an array and play it from there. There may be libraries that hide the details of that, but in the end your buffer is going to be played from RAM.
I see. In that case, could I only read the data in chunks at a time? I don't know if this would work with the analog wave library or if i'd need to use a more manual solution
That is exactly what you're going to have to do. I did that once upon a time with the Audio library and a Feather M0. If memory serves, the library used a timer interrupt to keep the DAC fed regularly. I may or may not have had to modify the library to get it to work with the Feather (and as I wanted it to work) as it was designed for the Arduino Zero; it's literally been years. So yes, it can be done. I imagine if you look around you might find that someone's already done the same thing for the R4.
As for changing the pitch, there you are likely on your own. But on a few seconds thought that ought to be fairly trivial.
teensy has an old but great audio library to play with
Finally I see TMRh20/TMRpcm Arduino ---
"If using an amplifier, consider that the output is a choppy digital PWM signal, not a smooth analog signal."
It still beats beep and boop.
OP Said
I don’t think that library lets you insert sample manipulation algorithms - that’s why I mentioned teensy and the audio library.
Typically messing up with an audio file’s frequency involves changing the playback rate or using short-time processing.
Changing the playback rate means reading the samples faster or slower than they were recorded. This shifts all frequencies proportionally but also changes the duration. The main artifacts are temporal distortion and pitch–time coupling, meaning the sound becomes shorter and higher or longer and lower, and transients can sound unnaturally sped up or slowed down.
Using short-time processing means splitting the signal into overlapping frames, modifying their phase evolution to impose a new instantaneous frequency, then reconstructing the signal; at a high level this requires repeated windowing, Fourier transforms, phase manipulation, and overlap-add synthesis, and it can introduce artifacts such as phase smearing, loss of transient sharpness, and a characteristic “phasiness” if not handled carefully.
The best algorithms combine frequency-domain processing with transient detection and phase-locking or hybrid time-domain techniques, so they preserve attacks and reduce smearing while maintaining stable pitch over time, although some residual artifacts remain unavoidable.
You need a pretty fast hardware with lots of RAM and solid access to the data source if you want to do any it this in real time .
Big mistake the analog wave library is a bit useless. This is because it squeezes all the waveform into a tiny space. Better to use just direct calls to the hardware and have a proper sound synthisis algorithem.
See this video
And this one
If you look carefully you will see a glider crash into a oscillating pattern.
This last one also has a link to the code that is used.
I'm thinking more of a granular synthesis style. Currently, I have a functioning device that uses the analog wave library to play a array of samples. I have an array on the Arduino named sound, and I create the wave with
analogWave wave(DAC,sound,300,50);
and then use
wave.begin(440)
and to change the pitch,
wave.freq()
in the void loop so I change the frequency in any way I chose. I would like to be able to insert a slightly longer sound with a longer sample rate, but the Arduino only has 256kb of flash memory. I probably should have been more spefific in my initial post.
I think I'll give the TMRPCM library a shot, since I can change the sample rate with that. Thank you for the advice. I'm very new to Arduino, I only started using it about a month ago, and I created this account to post this question.
Thank you for the advice, I'm going to try using this
isn't TMRpcm fundamentally limited to AVR hardware - I don't think it will run on your Arduino Uno r4.
is there any library like TMRPCM that is compatible with Arm architectures? or is there a board with the same amount of or more power than an Arduino uno r4 wifi that is compatible with avr? I'm trying Google as we speak.
edit:I'm currently trying to do manual read and write for the SD card with the SD library, since no libraries quite meet my needs. Thanks for the advice though, evreyone
There is also the TRMh20 Auto Analog Audio library that supports MCUs with DACs, rather than requiring PWM audio. It is said to work on SAM processors, and might not be difficult to adapt to the Uno R4.
Then that is easy. The box that says "Generate sample" uses the granuals you want to use.
I told you that the analog wave library is useless.
If you want to get anywhere with this project learn to take the advice of people who know what they are talking about.
I did take your advice, I was just giving some info I should have given at the start. Before posting this forum post, I made a device which outputs a wave continuously using the analog wave library. I found the main issue was that the wave had to be hard coded in, and had to fit on either the 32kb of SRAM or 512kb of flash/program memory. If you read the rest of my reply, you would have seen at the bottom I said I was going to give the TMRPCM library a shot. I then learned that library wouldn't be compatible, and then decided to do it with just the SD and SPI libary. Thank you for your advice.
An SD card in read-only use is generally stable in throughput, but you should not assume perfectly constant latency.
The card itself will not perform background writes during normal operation. However, internally it may still do occasional housekeeping operations such as wear leveling metadata updates or error correction bookkeeping in flash translation layers. These operations are typically small and not user-visible as explicit writes, but they can introduce short internal delays.
In practice, the main source of throughput variation is the controller’s garbage collection and block management. Even when you only read, some SD controllers may briefly stall reads if they need to reorganize internal mapping tables or refresh weak flash cells. This is not frequent in well-designed cards, but it exists and is not fully deterministic.
So you can expect fairly stable average throughput, but not hard real-time behavior. Occasional short stalls are possible, typically on the order of milliseconds, sometimes longer on low-end or nearly full cards. This is something you’ll need to take into account if you want a stable output.