esp8266 reboots while playing mp3

[Kalki2898add]

cant play mp3 from spiffs or stream online. while playing the mp3 esp reboots
i increased the sample rate to 8192 same problem
i set the cpu freq of esp8266 to 160mhz
i selected v2 higher bandwidth
flash 4MB (2MB fs OTA 1029KB)
even i changed the links and played from spiffs
but same problem

...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
...Connecting to WiFi
Connected
Running for 8453 ms...
STATUS(buffer) '2' = 'Refilling buffer'

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Exception (3):
epc1=0x402045fa epc2=0x00000000 epc3=0x00000000 excvaddr=0x4025f00e depc=0x00000000

stack>>>

ctx: cont
sp: 3ffffb40 end: 3fffffd0 offset: 0150
3ffffc90: 00000000 00000000 03c20002 00b3006f
3ffffca0: 0000000d 3f060c19 060500ff 03000000
3ffffcb0: 00040401 00000003 00000000 05000000
3ffffcc0: 40100005 3b98d8f0 00000046 3fff0540
3ffffcd0: 3ffef040 002601c0 000d00ac 180b0000
3ffffce0: 3ffef003 00000201 00000000 00000000
3ffffcf0: 0088b4f1 3fff041c 3fff023c 402311fa
3ffffd00: 3ffef040 00000000 00000000 03cd213b
3ffffd10: 00b500bb 0000000d 3f0a0618 0708c382
3ffffd20: 3ffef040 3fff041c 3fff023c 00000000
3ffffd30: 3fff053c 00000000 3fff053c 4022c201
3ffffd40: 0000c068 0000180d 00090186 000700ae
3ffffd50: 0f090000 00000009 3fff0001 000003cd
3ffffd60: 3fffb534 00000020 3fffb534 40100be4
3ffffd70: 3ffe9c88 00000000 00000000 40228c90
3ffffd80: 3ffe9c94 ffffffe1 ffffffe1 ffffffe1
3ffffd90: ffffffdb ffffffdf ffffffd9 ffffffd9
3ffffda0: ffffffe1 ffffffdb ffffffe1 ffffffe1
3ffffdb0: ffffffe1 ffffffe1 ffffffe1 ffffffe1
3ffffdc0: ffffffe1 ffffffe1 ffffffe1 ffffffe1
3ffffdd0: ffffffd7 ffffffd7 ffffffe1 40208dae
3ffffde0: 00000000 00002000 3fff03e4 40208ff8
3ffffdf0: 00000000 00000000 00000000 fffffffe
3ffffe00: 40214f30 3fffc6fc 00000001 3ffefc94
3ffffe10: 6000001c 00000002 3fff30ac 00000030
3ffffe20: 3ffe9c7c 00000008 3ffeeb38 40214824
3ffffe30: 3ffffe88 fffffffc 00000008 00000100
3ffffe40: 3ffe9c7c 7fffffff 00000000 3ffeeb38
3ffffe50: 3ffffeb0 00000008 3ffffe60 40210814 <
3ffffe60: 3fff30db 0008005a 40267ae0 27202972
3ffffe70: 3fff772c 3fff802c 3fff3148 00060000
3ffffe80: 0000036a 00000004 00000002 3ffffc90
3ffffe90: 40267ae4 3ffffd88 00000000 00000006
3ffffea0: 00000000 3fff40fc 00000000 3ffffc90
3ffffeb0: 00000000 00000000 3ffffe68 3fff772c
3ffffec0: 00000000 00000000 00000ad5 3fff36b4
3ffffed0: 3fff40b4 fffffffb 00000002 402670c8
3ffffee0: 00000000 3ffffc90 00000000 00000000
3ffffef0: 0000017e 3fff36e4 0000017e 0000017e
3fffff00: 00000000 0000017e 00000008 3fff802c
3fffff10: 3fff40fc 00000002 00000001 3fff36b4
3fffff20: 00000001 3fff40fc 3fff36d0 40201807
3fffff30: 3fff36ac 04000000 fffffff9 40208431
3fffff40: 00000000 00000600 3ffefe14 3ffeed10
3fffff50: 3fff40b4 3fff36b4 3fff40fc 40201930
3fffff60: 00000000 00000000 3ffe8664 3ffeed10
3fffff70: 0000270f 3fff2744 3fff2734 402096a4
3fffff80: 0000270f 3fff2744 3fff2734 40209801
3fffff90: 00000001 0000000a 3ffeeb38 3ffeed10
3fffffa0: 3fffdad0 3ffeeb38 3ffeea70 40207b49
3fffffb0: 3fffdad0 00000000 3ffeece4 40212bf0
3fffffc0: feefeffe feefeffe 3fffdab0 40100eb1
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3424, room 16
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8
tail 0
chksum 0x2b
csum 0x2b
v00072ef0
~ld

[nikkoxgonzales]

Have you found the solution on this?

[nikkoxgonzales]

I found the solution to this, just revert to 1.9.2 version of ESP8266Audio.

[MarcFinns]

I confirm that version 1.9.9 consistently crashes when trying to play MP3 on 8266 (in the loop function), while version 1.9.2 works fine.
Bug?

[nikkoxgonzales]

You can use up to version 1.9.4 for ESP8266. My best guess is that it may conflict with the latest libraries of ESP32.

[TexeCode07]

Same Issue I try playing mp3 from LittleFS

[MarcFinns]

I managed to play using an older version (1.9.7).
Interesting concept, a library called ESP8266Audio not working on ESP8266...?

[TexeCode07]

No the latest 1.9.9 version not working it causing load Prohibited error the old one 1.9.7 working Fine.
Seems like some changes in src/AudioGeneratorMP3.cpp cause.

[BScatterplot]

I have the same issue. I'm running an ESP8266 at 160 MHz. I'm running an MP3 from PROGMEM. v1.9.9 doesn't work, but changing to v1.9.7 works fine.

(I also get "MP3:ERROR_BUFLEN 0" in the serial debug port after the sound plays, in v1.9.7. Not sure if that's related or not.)

[Misterke]

@earlephilhower , how can this not be fixed yet? I've spent two days doubting my own code (which was largely copy-paste from an earlier working project) before finally figuring out the problem wasn't with my code, but with the latest versions of ESP8266Audio. As some others mentioned: it is a bit ridiculous to have a library with ESP8266 in the name no longer work on the ESP8266.

[samwh1te]

@earlephilhower , how can this not be fixed yet? I've spent two days doubting my own code (which was largely copy-paste from an earlier working project) before finally figuring out the problem wasn't with my code, but with the latest versions of ESP8266Audio. As some others mentioned: it is a bit ridiculous to have a library with ESP8266 in the name no longer work on the ESP8266.

Lucky this library is open source! You can lend a hand and submit a PR, or even write your own library. Thanks Earle for all the work you've done. Merry Christmas

[Misterke]

Crash seems to be introduced by commit b3c4166
More specifically the changes to src/libmad/layer3.c seem to be causing the crash, although I don't really understand why. The original contains several functions with a weird construct where you have an array of enums in PROGMEM and the function maps an input index onto a value from that table and the weird thing is how that function returns that value:

static inline mad_fixed_t ca(int i)
{
  static mad_fixed_t const ca_val[8] PROGMEM = ...;
  volatile uint32_t a = *(uint32_t*)&ca_val[i];
  return *(mad_fixed_t*)&a;
}

The commit moves the table outside of the function (which I tested and that doesn't make much difference) but also simplifies the function to what you would expect: a plain and simple return ca_val[i];, but apparently that latter change is causing crashes.

I don't really understand how that causes problems, but possibly the combination of PROGMEM and inline function can then cause a wrong type of memory access which is avoided by the weird construct ...

It seems a simplified version with a volatile variable is sufficient to avoid the crash: something like:

static mad_fixed_t const ca_val[8] PROGMEM = ...;
static inline mad_fixed_t ca(int i)
{
  volatile uint32_t a = ca_val[i];
  return a;
}

I'll try to prepare a PR with this change.

[Misterke]

I created a pull-request: #723

Still, I cannot understand how a commit that completely breaks basic functionality on the device that has its name embedded in the name of the library can just get merged and make it in 2 releases without being noticed ... Is there no testing at all done on ESP8266 before marking a new release?

[earlephilhower]

Espressif has a really great line of ESP32 devices today, and the 8266 is IMHO obsolete (and just a real pain compared to the ESP32r models). It was fun back 7(?!) years when I wrote this so I could make an alarm clock that played MODs and afterwards when I did a ton of work on the 8266 Arduino core. The 8266 had a value proposition that was hard to beat back then. In 2025, not so much. It's got ESP8266 in the name because back then that was the only game in town. Like they say, there are two hard problems in computer science: cache coherency and naming. 😆

Today, I am certain the vast majority of users here are ESP32 or Pico based, and I've personally moved on to the Raspberry Pi Pico family. Lower power, about same price, infinitely more RAM and capabilities (SWD is awesome). ESP32's got multiple CPU architectures and price points to hit all the sweet spots (and a great Arduino core, too). Granted, the ESP32 I2S interface seems to change and break things with every single IDF so it's not perfect, but I guess when you have to support such a wide HW variety things need to be refactored over and over.

The 8266 was the only system to be affected by this issue. Basically the compiler can legally optimize certain array accesses so they don't align to the PROGMEM requirements. The volatile that was there before the earlier patch, and reinstated here thanks to @Misterke , makes sure it doesn't get smart and optimize into something that crashes. We could bracket the changes with a #ifdef ESP8266 but it's not going to be that performance degrading on the ESP32 or Pico.

Neither the ESP32 family nor the Pico have these limitations, so my testing on those systems went swimmingly. In fact I forked and optimized the MP3 code a couple weeks ago for the Pico, dropping CPU utilization down to under 40MHz on the Pico. I may backport some of that here, especially the MP3 frame pump which here is not very good and can have a real bad time if the MP3 loses sync.

My point, in a roundabout way, is that given the limited free hours in a day I am focusing on the highest impact for me and I hope most users. I'm ecstatic to get PRs that work and fix bugs, especially when they're in parts I'm not actively experiencing. It's all open source so you're free to stick on the 8266 until they stop making them (looks like they extended it yet again) and continue throwing PRs out to the projects that support them. As for testing, on the 8266 I'm still running builds in CI so gross problems will be detected, but something runtime like this wouldn't.

Thx again for the PR!

[Misterke]

@earlephilhower , you're welcome. And I understand that focus shifts, but then maybe mark a known good version for each architecture at the top of the README, that way people don't get stuck with a version that doesn't work for their architecture. That would likely have stopped me from getting frustrated and then acting up like this ... My apologies!

Even with this problem fixed, I'm now stuck with mp3 playback from an internet radio stream giving almost always a 30Hz pumping noise with some audio barely audible in the background, whereas playback of an mp3 from LittleFS does seem to work. The source, buffer and mp3 generator seem convinced playback from the internet stream is fine, but the speaker disagrees. To make things worse: just a couple of times I did get decent audio out, making it even less clear where the problem could be. Perhaps also for this I should try going back to an older version?

PS: Main reasons for wanting to use ESP8266:

• I don't have an ESP32 lying around (order from Ali is underway)
• Price - I'm unsure where you get yours, but I can't find a pico w anywhere near the price of a d1 mini clone
• Power consumption - as I want the thing to run a reasonable amount of time on an 18650 battery

[earlephilhower]

I'm not actively trying to break things for the 8266, but things can just fall through the cracks as it were. So theoretically it all works for everything (module MIDI on the ESP32 Xtensas where there is compiler bug that gets tripped). I'll leave this settle to make sure we're good over the break and drop a new release Jan 1st week.

The MP3 over HTTP is very tight on the 8266 with this architecture. It's really CPU bound with the ESP handling the WiFi and the MP3 decode and the I2S DMA. When the stars align it works well! But what's worse is that the 8266 may block in some WiFi code behind the scenes, doing a busy wait even while there is data ready to decode. So no data is "lost" but you get hiccups like that. Having real coroutines would help, but w/the blob WiFi driver that's not really possible. The current architecture also suffers from relatively high CPU usage on silly things like VTable indirection. On a real CPU there's a BTB so you 're not stalling on a branch you've already taken, but here I don't believe any of them have this feature. So while having an object with abstract base class for outputting is what they'd teach you to use in CS101, it isn't so hot here. Especially if you take that indirect for every single sample. The XIP cache also probably gets thrashed quite a bit.

The rewritten stuff takes the same MP3 code and breaks it into real asynchronous processes. WiFi streaming and UI is independent from MP3 decode in the redesign. It also uses block-based decode of the full 1152 samples, so while there is still a vtable jump per audio data write, there is only 1 and not 1152. By doing that I'm able to get rock solid HTTPS (same BearSSL software I ported to the 8266 runs on the Pico) streaming and web interface on a 133MHz Pico with CPU to spare vs. stuttering on a 160MHx 8266. Granted the raw WiFi processing is on the offboard interface chip so it's not exactly apples to apples, but it's silky smooth nonetheless.

Price, you are absolutely right. 8266 is cheap as dirt. But advanced debugging on the ESP32 or Pico saves so much time it's worth it for me. It also is nice not trying to fit everything in 40K available (i.e. HTTPS + MP3 can't actually fit in RAM on the 8266). We spent most of our time on the 8266 core trying to shave a byte off of this or that. Power, the newest ESP32 1-core RISCV are pretty nice from what I've seen. And they have SWD debug and lots more RAM.

I think you're going to be a happy camper when that AX order arrives. :)