I'm having trouble with playing sounds from an SD card. I have one of these SD card readers with one of these speakers. I'm using an Arduino Uno with the PWM pin 9 inputting into the speaker. As the title says, I'm using the tmrPCM library.
Whenever I try to play a .wav file, it just makes a hellish screeching sound. All adding a resistor did was make the screeching quieter. I googled this issue and found potential fixes such as setting quality to 1, decreasing volume, increasing the buffer size in PCMconfig.h, and uncommented some other defines in PCMconfig.h, and none of these worked. If anyone has experience with this library and can help I'd really appreciate it.
Edit: Is it possible this is caused by the .wav files being more than 8 bit and more than 32KHz?
ShadowShine57:
Edit: Is it possible this is caused by the .wav files being more than 8 bit and more than 32KHz?
Always check the documentation. This is straight from the TMRPCM page:
Main formats: WAV files, 8-bit, 8-32khz Sample Rate, mono.
All adding a resistor did was make the screeching quieter
You should NOT directly-connect a 4 or 8 Ohm speaker! (A piezo transducer* is OK.)
The "absolute maximum" current allowed from an Arduino I/O pin is 40mA (with 20mA maximum recommended). From [u]Ohm's Law[/u] we can calculate the minimum resistance/impedance of 125 Ohms. Anything less than that, you get excess current, the Arduino will start to overheat, the output voltage will drop, and unpredictable bad things can happen.
You can use a piezo transducer, or add a series resistor and live with the reduced volume, or you use an amplifier, or you can use regular powered-amplified computer speakers.
But be careful with an amplifier or amplified speakers... As you may know, the Arduino doesn't have a true-analog output so TMRpcm is putting-out high-frequency PWM. If that PWM is not filtered you are putting high-frequencies into the amplifier and again "bad things" can sometimes happen. (So use an amplifier or powered speakers that you don't really care about... You might be OK but don't run the TMRpcm output into your home stereo!)
- Make sure to get a "transducer" or "speaker". Piezo "buzzers" run from DC and they have a built-in sound generating circuit so they don't work as speakers. But watch out and check the specs. Some cheap sellers on eBay, etc., use the wrong descriptions.
BJHenry:
Always check the documentation. This is straight from the TMRPCM page:
Do you think that will cause screeching though, or is the screeching caused by some other problem? (I cannot test the new compressed audio files until later)
DVDdoug:
You should NOT directly-connect a 4 or 8 Ohm speaker! (A piezo transducer* is OK.)
The "absolute maximum" current allowed from an Arduino I/O pin is 40mA (with 20mA maximum recommended). From [u]Ohm's Law[/u] we can calculate the minimum resistance/impedance of 125 Ohms. Anything less than that, you get excess current, the Arduino will start to overheat, the output voltage will drop, and unpredictable bad things can happen.
You can use a piezo transducer, or add a series resistor and live with the reduced volume, or you use an amplifier, or you can use regular powered-amplified computer speakers.
But be careful with an amplifier or amplified speakers... As you may know, the Arduino doesn't have a true-analog output so TMRpcm is putting-out high-frequency PWM. If that PWM is not filtered you are putting high-frequencies into the amplifier and again "bad things" can sometimes happen. (So use an amplifier or powered speakers that you don't really care about... You might be OK but don't run the TMRpcm output into your home stereo!)
- Make sure to get a "transducer" or "speaker". Piezo "buzzers" run from DC and they have a built-in sound generating circuit so they don't work as speakers. But watch out and check the specs. Some cheap sellers on eBay, etc., use the wrong descriptions.
Thank you for the information
Do you think that will cause screeching though, or is the screeching caused by some other problem? (I cannot test the new compressed audio files until later)
Most-likely, yes... If the audio data gets "scrambled" you'll get noise. It can happen if the bytes get scrambled-around or if you play a compressed file without decompressing it. (Compression is a lot like encryption.)
8-bit uncompressed mono audio data is pretty-foolproof because one-byte is always one-sample and as long as they get re-assembled in the correct sequence and played at the correct sample-rate, you're good-to-go!
I don't know what TMRpcm is doing with the incompatible format but if you've got 16-bit data and the software is reading it as 8-bit data, you've got "junk". If you were just reading the high-bytes and ignoring or throwing-away the low-bytes it could work, but that's probably not what's happening.
A sample rate error will usually just cause a tempo & pitch error. But, if TMRpcm can't read fast-enough, who knows what will happen... It might play too-slow or some data may simply be lost, causing glitches, noise, or distortion, etc.
DVDdoug:
I don't know what TMRpcm is doing with the incompatible format
Still plays it.
It only cares about finding the string "WAVE" exactly at the 9th byte and sample rate. If you enable the right options, the library will also handle channels/bit depth and ID3 file-embedded tags.
However, the playback will fail only if the string wasn't found at the fixed location; otherwise it will go on no matter what. Pretty dumb I know, considering there's even more data in the header to care about.
DVDdoug:
but if you've got 16-bit data and the software is reading it as 8-bit data, you've got "junk". If you were just reading the high-bytes and ignoring or throwing-away the low-bytes it could work, but that's probably not what's happening.
And it gets even worse when sign doesn't match. If the library always assume unsigned samples, then at 16-bit audio will suck a lot because at that "bit depth" samples are usually encoded as signed integers.
DVDdoug:
But, if TMRpcm can't read fast-enough, who knows what will happen... It might play too-slow or some data may simply be lost, causing glitches, noise, or distortion, etc.
Plays slower if sample rate is greater than 32 KHz (or if it's stereo and the feature is disabled); and buffer overruns aren't actually handled so distortion (in the form of repeating already played samples or overlapping data blocks) is most likely to happen.
So yeah... TMRpcm works but it's not that "foolproof".