ESP8266 Community Forum

- Mon Aug 14, 2017 9:55 pm #69074

Wow that looks fantastic. You are really good.
I bet you could even put a radio selection option on this and stream internet radio with this.

Just added that, too. About 20 minutes to write a HTTP stream based AudioFileSource class and example. It's not the most robust or memory-efficient thing out there, but it works as a proof of concept quite well. Pull it from the GitHub.

The problem, just like the NONOS build, is that there doesn't seem to be enough oomph to stream w/o stuttering at 128K/44.1. SPIFFS or PROGMEM of the same configuration runs like a champ, so it's either WiFi is eating the CPU like mad, or the incoming TCP is being buffered too long or slowly.

- Thu Aug 17, 2017 10:34 am #69184 Superb! I read this when you first posted & I've just had a moment to try it.

- Thu Aug 17, 2017 12:59 pm #69196

very nice!
what about SD card support?
there's no file seek(pos, dir) only seek(pos)

To run off of SD cards you'd need to write a wrapper subclass, similar to the AudioFileSourceSPIFFS class. All this class does is unify the different "filesystem" classes into one simple interface the consumers can use. I think a SPIFFS File != a SD File, for example, so instead of writing two players just wrap the appropriate calls with a simple base class. None of the players need any seek other than absolute, so no seek(pos,dir), just seek(pos). In fact, I think the only seek required is with the MOD player to pull different samples and events into RAM, the MP3 and WAV just read sequentially.

If you look at the SPIFFS one, it just has a local SPIFFS File class variable and runs 1-line wrappers for each of its methods. The SD one would be the same idea, but I don't have a SD card reader hooked to any of my ESP8266 to test. The examples would still work fine, you'd just need to change the class in setup() from AudioFileSourceSPIFFS to AudioFileSourceSDCard and recompile. the .ino.

This all is clear for me. I wrote wrapper based on SPIFFS.
mp3 file is opened, I can read file size (getSize) and check isOpen but I only get msg "MP3 done" from main loop

You do not have the required permissions to view the files attached to this post.

MY GITHUB: https://github.com/reaper7/

SDM Energy Meter: https://github.com/reaper7/SDM_Energy_Meter
MLEDScroll (TM1640 led matrix): https://github.com/reaper7/MLEDScroll

- Thu Aug 17, 2017 2:51 pm #69204

...This all is clear for me. I wrote wrapper based on SPIFFS.
mp3 file is opened, I can read file size (getSize) and check isOpen but I only get msg "MP3 done" from main loop

Just eyeballing it at lunch, now, but I think you forgot to override getPos. Without that, the buffering bit of the MP3 wrapper may get confused. I'll dig a bit more tonight. Also, w/getPos you can implement full seeking since you know the current position and can just add the offset on SEEK_CUR. If the SD lib doesn't give a ftell() equivalent, you can keep track of it yourself on reads and/or seeks...

[edit]
Actually, getPos is only used in the MP3 for error reporting (i.e. lost sync at byte XXX). Are you getting any "lost sync at byte XX" warnings? There's an initial one always at byte 0 because that's just the way the mp3 decoder was set up (it sets flags to resync @ byte 0 and everything runs fine from then on).

If you're not getting the lost sync at byte 0 warning then the file's not opening or not reporting being opened. Do you need a leading "/" in the SD libs? You need it for SPIFFS, which threw me for a loop more than once.