Memorystream: fast looping - small delay at first play

[veitk]

so after my mixer is working PERFECTLY !!!
now i have a tiny problem (just a "schönheitsfehler") doing quick loops - but in that case not loops after the sound has finished.

so for my little game the user presses the fire button and the firing sound is played - if he keeps pushing the button then it is set to "autofire" - so every 125ms i reset the sound by calling begin()

BUT: the first sound is played longer (maybe 200ms) and then it repeats correctly with 125ms. i logged everything, it is always triggered at 125.
(it is not delayed to start, it plays to long somehow)

AND: if i let go of the button and do not wait until the sound has finished and press the button again - it is also perfect. after the sound finished the behavior is the same as before.

sorry it is easy to hear but not easy to describe ;-)

expected:
pew pew pew pew pew peeeeeew (i let go of the button at the end and the sound is played completely till the end)

but it is:
peeeew pew pew pew pew peeeeeew

here my code from the loop ( i debounce by setting a timestamp in an interrupt. and i have a mixer for a sound if i get hit or something else)

void loop(){

  if (buttonLeftChanged && (millis() - lastBounceTime) > debounceDelay) {
    buttonLeftChanged = false;
    currentState = digitalRead(buttonLeft);

    // BUTTON changed?
    if (lastButtonState != currentState) {
      lastButtonState = currentState;
             
      if (currentState == LOW && ammo > 0) {   //Button pressed resets the sound
        autoFireStartTime = millis();
        Serial.println("FIRE button pressed!");
        shotSound.begin();
        playSound = true;
        ammo--;
        displayChanged = true;
      }
    }
  }

// ...

 if (playSound) {

    // autofire?
    if (currentState == LOW && (millis() - autoFireStartTime) > 125 && ammo > 0) { 
      autoFireStartTime = millis();
      Serial.println("autofire!");
      shotSound.begin();
      ammo--;
      displayChanged = true;
    }

    if (!mixCopier.copy()) {
      Serial.println("finished playing sound");
      playSound = false;
    }
  }

[pschatzmann]

Here are my 2 cents: Audio is only played smoothly if all the necessary audio data is provided in time. If you put everthing into one big fat loop there is a risk that this might not be the case.

If I would design a game, I would put the audio output into a separate task and manage the output via an audio queue. If you want to move into this direction, I suggest to have a look at this library which should be pretty easy to use.

Alternatively you can call copier.copyAll() which plays the whole "file" - but blocks the user from doing any actions, while the audio is processed.

Your logic with all the state variables is quite difficult to understand and to reason about. I would recommend to use a much more declarative approach like in this example

[vkjambit]

quite a while ago ... thx for your input.
i removed all the stuff and used your new "AudioActions" - which are nicely debounced.

here is the interesting thing:
if the copier finishes once, the problem occurs again:

so i press the button, sound is playing, after 125ms i call sound.begin() - but it takes around 200ms, after that it starts the sound again after 125ms until i let go of the button.
if i let go of the button the sound plays until the end (around 1 second).

IF i push the button again during that 1 second, the delay is only 125ms!!!

so it seems to me the sound is somehow in a cash, but if the sound is finished the cash is deleted.
it would be great if i could somehow keep it in the cash....

otherwise it works really well. even if i add a mixer, it is really cool.

[pschatzmann]

I am sorry but I dont quite understand what the problem is.
If you want to decrease the lag you can decrease the i2s buffer....

[vkjambit]

you didn't understand my problem and still fixed it ;-)

i set the buffer_size to 128 and it just works.
i can now restart the sample after 125ms as long as i push the button and it will play to the end if i let go of the button.

thank you!

[vkjambit]

i just saw that i used a different github account as i answered the question. reducing the i2s buffer is the answer to the problem.