MAX98357A Crackle and Pops

[RDJunc]

I am surprised that this has not come up more in this forum as it is a big deal practically everywhere else. (Maybe this is good thing as it is resolved!)

It is very common when using the MAX98357A to have excessive crackling during playback. There have been a number of proposed solutions but what I have found is that it is most likely cause by excessive ringing on the LRC and/or BCLK lines. This would be less of an issue with custom boards where the distance from the microcontroller and the amplifier can be very short. The modules from Aidafruit, where wire lengths can be long, do not mitigate this. As is my practice with data lines like this, I added low value resistors on those lines and that cleared up the crackling. I typically use 27 ohms but anything from 10-50 should work just fine.

What I have not been able to solve is the pop sound between plays. Scouring the Internet, especially the Raspberry Pi crowd, turns up the idea that the popping is caused by BCLK not being present before LRC starts. It is suggested that if BCLK is never stopped, this would not be a problem. Not sure how that could be done. It may be at the I2S level.

One workaround is to use the SD Mode line. The voltage on that line sets the mix of right and left channels but if pulled all the way down, it mutes the amplifier. Using that line and putting in mute periods of very short duration is supposed to take care of that problem.

So my question is within the context of these Audio Tools, how can this be done. Or is there some other solution that I am unaware of? FYI, here is my code....

`

#include "AudioTools.h"
#include "wavBell.h"

MemoryStream Bell(wavBell_wav, wavBell_wav_len);
I2SStream i2s;
EncodedAudioStream EncAudio(&i2s, new WAVDecoder()); // output to decoder
StreamCopy copier(EncAudio, Bell);    // copy in to i2s

unsigned long tmrBellInterval = 10000;
unsigned long tmrBellStart = millis();
constexpr auto pinSD = 7;

void setup() {
    Serial.begin(115200);
    //AudioLogger::instance().begin(Serial, AudioLogger::Info);  

    // begin processing
    auto cfg = i2s.defaultConfig();
    cfg.sample_rate = 24000;
    cfg.channels = 1;
    cfg.pin_data = 0;
    cfg.pin_bck = 4;
    cfg.pin_ws = 5;

    pinMode(pinSD, OUTPUT); digitalWrite(pinSD, LOW);

    i2s.begin(cfg);
    EncAudio.begin();
    Bell.setLoop(true);
}

void loop() {

    if (Bell.available()) {
        copier.copy();
    }
  
    if (millis() - tmrBellStart > tmrBellInterval) {
        Bell.setLoop(false);
        //stop();        
    }
}

[pschatzmann]

I never had any pop sounds between plays, so the first thing I would suggest, is to check your audio file: - Does is start and end with a 0 ? If not, you can adjust your file (e.g. by fading in and out) or if it is data related, a MedianFilter should also help.

If the i2s configuration autoclear is set (which is the default setting), i2s automatically sends 0 if no data is available. So the case that you described can not really happen.

Of cause you can always send silence when there is a pause, which would have the same effect.

You can use a VolumeOutput to determine the volume or the result of the copy() call to check if you processed any data and use this information to activate/deactivate the amplifier

[RDJunc]

This is most peculular. I checked the audio file. It does have natural fade ins and outs at the ends of the file. To be extra certain, I added fade ins and outs, not just at the beginning and end of the file, but between each bell ring. (There are four bell rings in the file that is then repeated as many times as needed.)

I have tried two ways to repeat the file. One was to set loop true. The other was to execute copier again and again until the duration requirement was met. No difference in performance. The sound is crystal clear but there is a pop between repeats.

It should be noted that there is no pop when the file is first plays. There is also no pop after the last time the file is played. This indicates that there is nothing wrong with the audio file and data. There is some funny business going in with the process of repeating the file. This could very well be associated with when BCLK starts in relation to LRC.

[ld21]

@RDJunc How do you markdown code in order to «prettyprint» it in your github-article (as you did above)? I usually use the <> Button, but that makes my code look very bad and unformattet / uncolored. Thank you for your tipp! Dani

[pschatzmann]

Strange: what happens if you simplify the loop and you just call copier.copy() ?
Can you share your full sketch including the bell sound so that I can try to reproduce it on an AudioKit ?

[RDJunc]

Same thing. The pop occurs between replays, not at the start of the first or after the last. The bell sound is attached as a .txt file, not a .h file. I don't know why this is but pasting code does not come across in one piece but here goes...

#include "AudioTools.h"
#include "RRCrossingBell01A.h"

MemoryStream Bell(RRCrossingBell01A_wav, RRCrossingBell01A_wav_len);
I2SStream i2s;
EncodedAudioStream EncAudio(&i2s, new WAVDecoder()); // output to decoder
StreamCopy copier(EncAudio, Bell);    // copy in to i2s

unsigned long tmrBellInterval = 5000;
unsigned long tmrBellStart = millis();
constexpr auto pinSD = 7;

bool LastPlay;

void setup() {
    Serial.begin(115200);
    //AudioLogger::instance().begin(Serial, AudioLogger::Info);  

    // begin processing
    auto cfg = i2s.defaultConfig();
    cfg.auto_clear = true;
    cfg.sample_rate = 22050;
    cfg.channels = 1;
    cfg.pin_data = 0;
    cfg.pin_bck = 4;
    cfg.pin_ws = 5;

    pinMode(pinSD, OUTPUT); digitalWrite(pinSD, LOW);

    i2s.begin(cfg);
    EncAudio.begin();
    Bell.setLoop(false);
}

void loop() {

    if (Bell.available()) {
        copier.copy();
    }
  
    if (!copier.copy()) {
        if (!LastPlay) {
            Bell.begin();
        }
        else {
            i2s.end();
            stop();
        }
    }

    if (millis() - tmrBellStart > tmrBellInterval) {
        LastPlay = true;        
    }
}

RRCrossingBell01A.txt

[pschatzmann]

....and I forgot: did you set the log level to Warning to avoid any disturbing effects from the logger ?

[RDJunc]

The AudioLogger is commented out altogether.

[pschatzmann]

Your click comes from the WAV header!
By default the wav MemoryStream starts at the beginning with a header. If you setLoop(true) it restarts at the beginning which is the wav header that is interpreted as audio data!

Solution Alternatives:

• export as Audio / signed 16 (so that there is no header) and not as wav or
• after looping, call EncAudio.begin() to tell the encoder that there is a header (there is a callback which is executed after the loop) or
• after looping, reposition the pointer to ignore the first 44 bytes
• upgrade to the latest library version and indicate the start position by calling setLoop(true, 44);

[RDJunc]

I have been watching your edits! I am using Audacity to export the audio file. The only headerless option was as a RAW file. My first attempt did not work but probable because I did nothing else in the code expcept to change the wav in the file names to raw. StreamCopy failed.

I will upgrade to the latest library and try your last option. Is the header always 44 bytes?

[pschatzmann]

Yes, my library assumes that it is always 44 bytes...
RAW will work directly w/o any need for a decoder

[RDJunc]

OH MY GOD! It worked. It was the HEADER!!!!! You have solved a problem that has plagued every single user of these devices. This is information that must be disseminated quickly and thoroughly. I will do my part.

So, for just this first test, all I did was to encode it out a RAW and with no header. I changed the code to reflect the change from WAV to RAW. I left the code as is that restarts Bell when copier is not true. NO POP! I will now change the code to use the loop condition but I expect it will work fine.

All that being said, I think it is probably best that these functions have the ability to automatically not attempt to play the header if present. Not in my case for this application but others will be using WAV, MP3, and other file formats that will have headers in them. You would obviulsy know best how to handle this but it sure would help if this could be resolved in an almost straight forward way.