Small snippet of previous radio station audio is played when playing from file is started

[Frank-Bemelman]

Hi Cellie,

Some thoughts here...

stream.stopSong() does stop a playing radio station, but somehow the buffers aren't completely emptied, or maybe it is not the buffers on the ESP side of things, but some buffer in the VS1053 - just wild guessing here.

Once a radio station is stopped, and a mp3/wav file is started, I hear a very short snippet (sometimes sound as an audible click) of that last radio station. The next mp3/wav file starts without that snippet/click.

Tried a lot, to no avail.

My last attempt seems to solve it, where I use it in my own application code:

stream.stopSong(); // stop whatever stream or file was playing
chunkplayer.switchToMp3Mode(); // which does a softReset() also!
stream.connectToFile(SD, filepath); // play it

---

Moved it to function void ESP32_VS1053_Stream::stopSong(), just at the very end of that:

void ESP32_VS1053_Stream::stopSong()
{ ...
...
_http->end();
delete _http;
_http = nullptr;
_bytesLeftInChunk = 0;
_dataSeen = false;

_vs1053->switchToMp3Mode(); // does a softReset() also !!

}

---

Anyway, no weird extra sounds anymore, when switching from radio station to file playing.
Although I do still hear a noisy-click when switching between radiostations.

Hope that helps.
Cheers, Frank

[CelliesProjects]

Hey Frank,

That wont do as is.
Soft reset breaks pause and resume implemented like this.

[Frank-Bemelman]

Oops, I didn't even know there was a pause/resume mechanism.
Also been trying to do a fade-in volume, rather than switching between 0 and the desired volume level. Slowly turn it up, over a period of 200mS or something..

[CelliesProjects]

@Frank-Bemelman

Please check if #110 fixes the issue.

[CelliesProjects]

Oops, I didn't even know there was a pause/resume mechanism. Also been trying to do a fade-in volume, rather than switching between 0 and the desired volume level. Slowly turn it up, over a period of 200mS or something..

There is not really. My player app can only switch to the start of the next stream, then the vs1053 locks and then you can just connecttohost/file to within the current playing with an offset. So playing from the start of the file is mandatory atm. Once started and locked you can zap around. Once you switch url/file you need to re-lock from the start of the file.

Fixing that will be a future headache.

[Frank-Bemelman]

I only did that _vs1053->switchToMp3Mode(); thing when stopSong() had a radio stream to stop. Thought it was ok, as when stopSong() is used for stopping a file playing, it returns early.

But since I am really like Alice in Wonderland here, I don't oversee all the possibilities. I see that you now compare the current url/file with the new one. That's also good, I guess ;-)))

Thanks a lot!

[CelliesProjects]

@Frank-Bemelman The current master branch might fix your issue depending on which version you tested against.

[Frank-Bemelman]

Hi Cellie,

I tried your suggestion #110 but it does not work, it gives eof_stream on files trying to play, faster than loosing api keys ;-)

The partly good news however, if I replace the _vs1053->softReset(); with _vs1053->switchToMp3Mode(); it works beautifully at first glance. No clicks/snippets at the start of a file (after a http stop) - but at the end of file playing, I get a half second of free pink noise sound. (or is it at the start of the next one, from the playlist - hard to tell.

I also noticed this behaviour with my first method ( _vs1053->switchToMp3Mode(); at the very end of ESP32_VS1053_Stream::stopSong() - if I replace that with _vs1053->softReset(); also all these instantly eof_stream occuring.

The weird thing here is, that if you look at the _vs1053->switchToMp3Mode(); code, that does a softReset at the end of that, I don't understand why that actually makes the difference that it does.

I'll leave it bit for now - to see if I stumble on some unexpected behaviour..

[Frank-Bemelman]

About` that snippet of pink noise, at the end of a file being played:

It goes like this: complete song plays -> short silence -> short (0,5s) snippet of pink noise.

Only happens when reading the SD barely keeps up with the playing, wavs or high quality mp3.

ESP32_VS1053_Stream::_handleLocalFile() is called continiously while playing.
When the audio stops (song ended) the _remainingBytes is still very high, 60000-150000
While the song has ended already, it continous to call this function.
When _remainingBytes reaches zero, I hear that snippet of noise.

In this function void ESP32_VS1053_Stream::_playFromRingBuffer() I made a small change:

   while (_remainingBytes && bytesToDecoder < VS1053_PSRAM_MAX_MOVE && _vs1053->data_request())
    {
      size_t size = 0;
        
      uint8_t *data = (uint8_t *)xRingbufferReceiveUpTo(_ringbuffer_handle, &size, pdMS_TO_TICKS(0), VS1053_PLAYBUFFER_SIZE);

//        if (!data)
        if (!size)
        {
            if (!_bufferStallStartMS)
            {

Instead of testing !data, I test on !size now.
This does wonders, in my case. When the song goes silent, my _remainingBytes is also zero.
And no extra snippet of noise.

It is strange, because I would think testing on !data should work, perhaps even the preferred way.
Or maybe xRingbufferReceiveUpTo() returns a wild pointer by accident, and checking size is more reliable. Wild guessing here..

I think this problem does not occur when the SD is faster than mine. I use 1-bit SD setup.
With my setup, playing wav files, the SD card reads 2048 bytes on every ESP32_VS1053_Stream::_handleLocalFile() call, only at the very end I see a smaller read and maybe 10 calls with skips, as the filepointer reached the end of the file. With mp3 files, 128kbps,
I see it skipping more, as it can keep up better.

Apologies for the long story..

[CelliesProjects]

No problem. Valuable insights.

For the local file playback I need to refactor my player software to be able to play those.
Atm I only test local file code in a test sketch not unlike the examples. To really test those cases I need a real world setup.
Working on that one atm.

[Frank-Bemelman]

Talking about valuable insights...
This problem of that shot of pink noise at the end -> it seems some wavs (most don't) have an embedded large data block, for instance containing a complete jpg file of the original album cover.

I think I will investigate how to detect that, at the start, then only reading the audio data from the file, not to the end of file.
Now that I realize such files exist, I think I can figure out how to skip/ignore that portion of data. Pulling my hear out all day, I hope it grows back.

Oh well ;-)

[CelliesProjects]

It might be that _remainingBytes needs te be calculated from some header values instead of just file size at the start of the file. Tbh I never test Wav or know anything about it. But that might be worth checking.

[CelliesProjects]

Now I am running into SPI bus contention problems listing SD content while playing and servicing the display.

CelliesProjects/featherplayer-esp32#33

I think I copy your setup of having a dedicated player board, one that has only SD and vs1053 with both on a separate spi bus.
And a separate frontend esp that just handles the display. This way I can be very flexible wrt the frontend hw.

All the display stuff is allready passed around with msg queues, I will probably implement that as a websocket connection to the frontend.

[Frank-Bemelman]

Yes, displays are really power hungry, and probably too much for one esp32 if you want the screen to react snappy.
For the communication I didn't use a regular websocket, but a direct p2p methhod, using ESPNOW. I am sending and also receiving 10 packets (structuresof 164-204 bytes) per second, and it doesn't travel through my router. Queues for both sending and receiving. Some variables are not processed by the queue handler, but have immediate effect upon receiving. Bit of a hassle to set it up, but I am not dissapointed with the performance.

I have some work done on handling of the wav header. Seems to work, just a bit more checking to do. Introduced a new helper variable _maxFiledatapointer, because checking the filepointer against _remainingBytes is debatable, since _remainingBytes relates to bytes to be played, and lag behind the file reading stuff.

I want it to be as clickless as possible ;-)

[Frank-Bemelman]

Wav files usually have an ID3 tag with metadata such as artist name and songtitle etc. Some even have a jpg with album art embedded. Playing a file just like it is, gives a short or longer shot of noise at the end. If it is only some metadata, it is short, sounds like a click, but if it is a jpeg, it can be a half second of noise.

So it is more or less mandatory to read the header, to figure out what the end of the music data is. And don't read/play from the SD than just that.

Here is my current code, plays the wav, not a byte too much or too less.

bool ESP32_VS1053_Stream::connectToFile(fs::FS &fs, const char *filename, const size_t offset)
{
    if (!_vs1053 || _playingFile || _http)
        return false;

    _file = fs.open(filename, FILE_READ, false);
    if (!_file)
    {
        log_e("could not open file");
        return false;
    }
    _file.setBufferSize(2048);

    _remainingBytes = _maxFiledatapointer = _file.size();
     
    // wav header check - figure out end of data to read
    if(strstr(filename, ".wav"))
    {  // wav header check - figure out end of data to read
      size_t bytes = _file.read(_localbuffer, 128);
      // parse header       
      if(bytes)
      { size_t bytesoffset = 0;
        while(bytesoffset<bytes)
        { if((memcmp(_localbuffer + bytesoffset, "data", 4)) == 0)
          { //Serial.println(bytesoffset);
            uint32_t maxbytes;
            bytesoffset += 4;
            memcpy(&maxbytes, _localbuffer + bytesoffset, 4);
            bytesoffset += 4;
            Serial.println(bytesoffset);
            Serial.println(maxbytes);
            _maxFiledatapointer = bytesoffset + maxbytes;
            _remainingBytes = _maxFiledatapointer;
            Serial.println(_maxFiledatapointer);
            break;
          }
          bytesoffset += 2;
        }  
      }   
    }

    if (offset >= _maxFiledatapointer)
    {
        _file.close();
        return false;
    }   

    _file.seek(offset);
    if (strcmp(filename, _url))
    {
        _vs1053->stopSong();
        snprintf(_url, sizeof(_url), "%s", filename);
        _vs1053->startSong();
    }
    _playingFile = true;
    _remainingBytes -= offset;
    _bufferIndex = 0;
    _bufferFill = 0;
    _bitrateTimer = millis();
    _vs1053->setVolume(_volume);

    return true;
}

The reading of the SD has to stop exactly at the end. So I had to modify this too:

void ESP32_VS1053_Stream::_handleLocalFile()
{ 
    if (!_file)
    {
        log_e("file error");
        _eofStream();
        return;
    }

    log_d("file pos: %lu", _file.position());
    log_d("remaining bytes: %lu", _remainingBytes);

    _updateBitRate();

    if (!_ringbuffer_handle)
    {
        _handleLocalFileNoPSRAM();
        return;
    }

    [[maybe_unused]] const auto startTimeMS = millis();

//    if (_remainingBytes && _file.position() < _file.size())
    if(_file.position() < _maxFiledatapointer) // no more sd read when file completely loaded
    {
        size_t free = xRingbufferGetCurFreeSize(_ringbuffer_handle);
        if (free > 1024)
        {
            size_t toRead = min(sizeof(_localbuffer), free);
            if(toRead > (_maxFiledatapointer -_file.position())) toRead = _maxFiledatapointer -_file.position(); // make sure the last read is not beyond the _maxFiledatapointer
            size_t bytes = _file.read(_localbuffer, toRead);
 
            if (bytes)
            {
                if (xRingbufferSend(_ringbuffer_handle, _localbuffer, bytes, 0) == pdFALSE)
                {
                    log_e("ringbuffer failed to receive %i bytes. Closing stream.", bytes);
                    _remainingBytes = 0;
                }

                log_d("%lu ms moving %i bytes localfile->ringbuffer", millis() - startTimeMS, bytes);
            }
            
        }
    }
    
    if (_remainingBytes)
     {//Serial.printf("> %d\n", _remainingBytes);
        _playFromRingBuffer();
      //Serial.printf("< %d\n", _remainingBytes);  
     }   
    else
    { Serial.println("Perfect end of file play");
      _eofStream();
    }   
}

The check only targets wav files.

Another approach could be to make this wav header check not part of this library, but leave it to the user. In that case the ESP32_VS1053_Stream::connectToFile(fs::FS &fs, const char *filename, const size_t offset) would need an extra parameter, to force the early end of the file, by the user.

Also not sure if this all interferes with your optional offset parameter.

[CelliesProjects]

Cool! Looks very reasonable. And I dont think it will interfere with pausing/resuming.