Page 2 of 2

Re: VS1053 EndFillBytes + Power Off "Plopp"

Posted: Mon 2020-06-29 22:29
by DrDoom
Hello Hannu,

i had alreay read your post. but I just got stuck. I understand that the GPIO's can be read / written via SPI. But even after several searches I did not find out which GPIO is for e.g. muting the audio output.
nothing is included in the data sheet either. Or do you think I should use a GPIO for a relay and the relay mutes the audio line?

Re: VS1053 EndFillBytes + Power Off "Plopp"

Posted: Tue 2020-06-30 7:51
by Hannu
I was thinking about external relay or muting chip and controlling it with GPIO.

VS1053 doesn't have internal muting circuit.

Re: VS1053 EndFillBytes + Power Off "Plopp"

Posted: Fri 2020-07-10 10:10
by DrDoom
What I've been doing lately:
1. I installed a capacitor with a diode. However, the capacitor (1000uF) appears to be too small. The plop has become a little less, but still exists. I have ordered a GoldCap capacitor (5.5V - 1.5 F) and will instal it as a test.
2. Referring to my first post (point 1), I have modified my library a bit because the remaining data in the buffer was played when I stopped playing (as described in "10.5.2 Canceling Playback"). The problem is annoying if I pause the playback and then end it later. Then "Canceling Playback" plays further data until SM_CANCEL is cleared.
At first I thought that SM_CANCEL would end the output immediately. But only seems to be in the decoder for resetting the audio information.

I have solved the problem as follows: the volume is set to "mute" ... then "canceling playback" is carried out and after 150ms the volume is "unmuted" again and it will continue with the next MP3 data (next file).
The 150ms are absolutely necessary for this workaround.

Unfortunately, I have not found any other information on pausing and stopping in the data sheet. Maybe someone knows a better way?

Re: VS1053 EndFillBytes + Power Off "Plopp"

Posted: Wed 2020-07-15 11:03
by pasi
The audio formats have varying audio block sizes and natural size of number of samples they output at once. It might also depend on the individual file (samplerate, bitrate). The more samples are sent to the audio output at once, the less overhead. So, decoders want to send as many samples as convenient.

Pause is more or less asynchronous to decoding. For example pause can be implemented at the DAC output, or in the data input. The decoder doesn't know about pause, as that would complicate the decoder, and/or you could only pause at certain intervals, which would make the response to pause lag.

The same applies to cancel. Cancel is only checked at some points of the decoding process. Due to pause being asynchronous, the decoder has almost always already sent more decoded data or will decode more input data after pause is released.

I have used a similar "mute" pause/cancel procedure in some VS1000 applications, i.e. when cancelling play, I set the volume to "mute" (but not powerdown) so that the remainder of the decoded audio doesn't get heard. When starting to play the next file, the volume is restored.