You should try running the code under a debugger or at least displaying it through something that will decode that stream of numbers under the "GURU MEDITATION" that's displayed after that. It may not show you the culprit, but it might offer hints.

In PlatformIO, that's just running it under the monitor https://docs.platformio.org/en/stable/tutorials/espressif32/arduino_debugging_unit_testing.html once configured as a filter Arduino has something similar. All of those tools are wrappers around Espressif's own stack decoder that they provide separately and as part of ESP-IDF.

Now, the mystery is why might the crash not be the actual offender? The error you're getting shows that SOMETHING was able to determine that the heap - the big chunk of memory where all allocations (malloc, calloc, operator new, etc) come from, where they live while they're in use, and the pool of memory that hasn't been allocated yet or that's been used and then returned. It's like a big bookshelf and as books get checked out, it's not like everything else gets pushed together. Eventually, something is determining that, for example, there's more space between books on the shelf than the shelf is long. That's "obviously" a crazy thing that should never happen, but if someone was a bad citizen and damaged the storage by scribbling into memory after it was freed (and possibly resused!) or trying to return (free) memory twice, that would also trigger as corruption.

Unfortunately, sometimes you don't get the error when that person returns the book twice; you get the error later. This is why this kind of crash can be tricky to track down.

There's a lot going on in this system, with network requests flying around, I2S buffers getting filled and emptied, SSD1306 updates happening, knobs getting checked and probably more.

I see three arrays in your code, but they're all in the .data section, not the heap, and just from inspection, I don't see any obvious overwrites in them. volumeReadings, numStations, and streamTitle don't seem to have any obvious overwrites. (I could be wrong.) The "hard" part of all this doesn't seem to be in your code at all.

I'd move some of that startup stuff outside of loop() and into setup(). Just for simplicity in debugging, I assume that display, Wifi, and audio each need to be initialized only and exactly once. I'd move them to setup.

Then I'd simplify the loop runner to just call audio.loop and leave the display and audio out of it. That at least gets you a simpler system to debug. If the problem remains, go back to the sample code from whereever your audio library came and see if it works. If so, compare the remaining source. If the problem goes into remission, add volume and screen handling back individually. Again, it may not be 100% their fault, but it at least lets you divide and conquer. Their https://github.com/schreibfaul1/ESP32-audioI2S/blob/master/examples/I2Saudio/I2Saudio.ino example may provide inspiration on a super minimalistic implementation.

Those are the tricks and tools I'd use to chase this down. Good luck!