Decoding error 0x0235 (bad main_data_begin pointer) at byte offset #9
Comments
|
Howdy, Can you please post those warnings you're getting? I compile with -Wall and don't get anything in the Audio library (but I do see stuff in SPIFFS and the main ESP arduino libs which I can't touch)... It looks like things are working fine, you're just losing packets somewhere. The decoder is resyncing and continuing to play from what I can see. Have you tried adding a buffer between the HTTPStream and the Generator? The README.md shows a simple example...as long as you have memory it's literally a 1-2 line change. Here's all I get on a clean compile w/-Wall using the latest Arduino and ESP8266Audio Git: |
|
And, as I felt bad having them hanging around, I just cleared up those 4 warnings with the latest push. No functional changes, just stuff to make GCC happy. |
|
Thanks for your response, is appreciated! The warnings in your post LOOK similar to mine, but I will check in detail later today, and report back. AND I will check the version with the 4 warnings cleared, nice work! And NO, i didn't try adding a buffer yet, just added my SSID and compiled the standard example sketch. My turn again, I will report back later. Thx. |
|
These are my warnings with the latest Arduino-ESP8266 GIT and with the former ESP8266Audio GIT: |
|
These are my warnings with the latest Arduino-ESP8266 GIT and with your latest ESP8266Audio GIT: |
|
Now running StreamMP3fromHTTP sketch from the latest GIT:
Is this the behaviour you expect from the sketch? |
|
Now tested the example in the README.MD playing the stream from http://mp3radio.com/playback" with the extra buffer. After uploading/resetting the ESP8266 the "MP3 done" starts immediately without the former "Decoding error" lines. Looks like SUCCESS to me!! Now searching for a working earpiece ;-) |
|
All those warnings you've got on the latest GIT are in the main Arduino code, not the audio portion. They're harmless, but I'm sure igrr wouldn't mind a PR if you want to fix them. As to the "MP3 done," that actually means the MP3 is..err...done, and not playing any more. So the socket got closed, the file was completed, etc. The example http address in the readme isn't a real URL. I thought it was obvious, but I guess not. You'll need to replace that with a real MP3 stream URL to run it. One other possibility is that the errors are related to things like ICY tags or ID3 or other form of station identification. |
|
Understand. For testing the sketch in the README I used the URL "http://streaming.shoutcast.com/80sPlanet?lang=en-US" used in the StreamMp3FromHttp example sketch. Tried this URL in a browser windows and the stream plays, si I assume it's OK for testing the sketch. But I still get every second the "Mp3 done" message. Now I know this indicates that no sound is played. Will do some more testing tomorrow. Thanks for your support so far in tackling my issues! |
|
Started again to do some testing to get this beauty working, sorry to bother you, again. TEST 1As "baseline" I uploaded example sketch PlayWavFromProgmem. Works perfectly, violin sounds through speaker system connected to RX :-) TEST 2Uploaded HTTP stream example from README, using the valid URL from the StreamMp3FromHTTP example. Result:
The sketch contains this line in Setup: I think this disables Wifi alltogether, and that would mean that playing the stream is impossible. TEST 3Uploaded StreamMP3FromHTTP example, URL="http://streaming.shoutcast.com/80sPlanet?lang=en-US". Result: This is the serial monitor output, some further suggestions, maybe, I'm getting banana's here! |
|
Yup, the README.md example was just intended to show how to add the buffer. That's what I get for cutting-and-pasting code in a text file and expecting it to work I'll delete it, you should start w/the Stream example and add the buffer instead. Try a different webserver, or your own sitting on your own network to start. I just picked the first working URL I could find for the example as I don't do any web streaming myself. Looks like you're having bad packet loss between your ESP and that streamcast server... |
|
Glad to help, grin! As said before the stream example (without buffer) "works" alternating good sound with silences. Just tried adding a buffer but that seemed to make things even worse. Also tried another URL (in my home country), but to no avail. Spent (to) many hours today, so I'll call it quits for now. Tomorrow is another day :-) Would be really pleased to get this working. I would love to have a couple of streaming ESP's. Thx. |
|
So it turns out that @armSeb, who's been doing lots of work with me recently, found a bug overnight in the buffer routine which would cause certain reads to return invalid data. You should do a pull of the updated repo and see if it changes things for you. |
|
Yep, it changes things dramatically! First pulled the updated repo and uploaded the example sketch StreamMP3FromHTTP (no buffer). Behaviour was similar as before with repeating "Decoding error" messages and eventually 1-sec repeating "Mp3 done" messages. Then added a buffer to the sketch. Sound plays with a disturbing hickup of 50Herz or so, but it plays continually, NO "Decoding error" and NO "MP3 done" messages anymore. Not sure where the 50?Herz hickup is coming from, but it is quite disturbing. But it is dramatic progress for me, it shows that my environment is more or less OK. Will do some more testing later. Good show! |
|
Hello, What is the MP3 bitrate ? |
|
For testing I used this URL, but I have no clue what the bitrate is, sorry: |
|
For fun I just tried the default URL in the sketch: Wow, NO 50?Hz hickups with this stream, perfect sound !!!!!! Just a "crackle" now and then. Also no idea what the bitrate for this stream is :-( |
|
It's 192kbit/s 48000 Hz. Please try with 44100Hz streaming ;) And for buffer, you can try 4096 or 8192 bytes. |
|
Great feedback on the example. I've just added buffering to the sample code so it's obvious to new users how to do it. |
|
@earlephilhower : Glad that I could give something back to you guys! |
|
@armSeb : Now that I know that bitrate is an issue I investigated the bitrate of the tested streams (opened stream in iTunes and showed INFO). These are the streams and results I tested so far (note : loooong lines, scrolling required): The 44.1kHz@128kbps work satisfactory, the 48kHz@128kbps stream has severe hickups. Increasing the buffer to 4096 : I THINK the number of small hickups decreased, but it may be wishfull thinking. Will do some more testing when I'm alone in the house, so not to bother them with the crackles and hickups :-) |
|
I think the issue is that at 48KHz the audio output portion that copies to I2S isn't being called often enough due to WiFi and other background ops taking time. The ESP8266 can decode samples at >> 48KHz with no problem, probably even @ 80MHz, but there's a minuscule I2S buffer of only 11ms @ 44KHz, which is <10ms @48khz. Even if you've got 20ms of data decoded and ready to go, only what fits in the I2S buffer will be used if there's a delay somewhere in the whole system. I've put in a PR to let a user app override this default, esp8266/Arduino#3790 , but it's obviously a low priority for them as they're releasing a new version soon and cleaning up existing features. The change is easy and you could hand-apply it if you're running the GIT head simply enough and set a larger buffer count. Are you using an I2S DAC or the SW one? If it's the SW one you are using more CPU (~10 more insns/sample) than the HW DAC, so that makes it even harder to hit 48KHz... One simple, if unappealing, way to work around this is to introduce a subsampler. It's not rocket science to downsample from 48KHz->44.1KHz if you don't care too much about noise floors, and then you gain an extra 1ms or 2 of time to play around in background tasks. |
|
@earlephilhower : Thanks for enlightening me re. the 48kHz issue. The fact is that I just happened to test using a stream that was MP3 @ 48kHz. The stream I'm mostly interested is an AAC stream @128KBPS. From your explanation I gues the small I2S is the major bottleneck. I read the PR and I think I can manage changing it to a larger buffer count. Before I'll go that route I'll refrain myself to getting "the best quality sound" using the current default. I'm currently using the SW DAC, one challenge at a time, right ;-) So for now, I'll focus on getting the AAC @128KBPS as good as possible. Then I'll know what imperfection I will have to deal with. Many thanks for the inspiration. |
|
@armSeb : did some more tests with different buffer sizes: |
|
8192 works for me, but I think the best compromise is 4096. You need free heap to be able to decode mp3 (and AAC) correctly. I received my SPI RAM chip, I need some time to plug it an begin the tests. If I can use it, this will bring 128kbytes of buffer, without eating the main RAM. |
|
@armSeb : Not sure why 8192 fails for me, but for now I'll stick with 4096. Adding extra RAM will certainly help. Too bad that it adds an extra component, the fact that it runs on "just" a basic ESP8266 with a speaker is magic. |
|
Yeah but with a real DAC you really get a nice stereo sound :) |
|
Stereo, hickups from 2 sides ;-) Seriously, a DAC is certainly worth the couple of $$. |
|
Really ? I bought this one : https://www.ebay.com/itm/PCM5102A-DAC-Decoder-I2S-32bit-Player-Module-Beyond-ES9023-PCM1794-Raspberry-Pi/331976578784 Without DAC you already have to decode stereo mp3, then converted to mono. |
|
I believe a saw an even cheaper one on Aliexpress, but can't find it right now. If I do find it again , I'll let you know. So the SW DAC wastes CPU cycles?, had no idea. I am more of a SW guy myself, but I guess there's no way avoiding a hardware DAC :-( Signing off for tonite. |
|
lwip2 seems less optimized than lwip1. But using lwip1 from the latest esp8266 git repo seems to be better than the stable version (more stable, more performant). |
|
lwip variants you can choose in the Arduino IDE are: The V2 default resulted in a lot of connection trouble i.c.w. ESP8266AUDIO, setting the lwip variant to Prebuilt source (gcc) solved these problems. Did not try the other variants to choose from, yet. The lwip variants for the IDE are defined in BOARDS.TXT, but did no further investigation https://github.com/esp8266/Arduino/blob/7315095e464397ae3f4dc9f1d231278e61242b04/boards.txt |
|
I choose the Open Source variant ;) |
|
Agreed, will do that to, hopefully without any regrets. |
|
Guys, I am the author of lwip2, and also very interested in this project. @earlephilhower does cool stuff :) I read above that you have buffers problem. There's something you can try with lwip2, it is to change MSS size. It is by default 1460 in lwip1, and I changed it to 536 (the minimum legal in RFCs) so to release memory for the esp8266. edit then recompile your sketch selecting lwip-v2 and please report back. I predict performances are at least the same as with lwip-v1.4. |
|
Unexpected Compile error using setting lwip variant to "Open Source (gcc)", and the compilation stops. It complains (in Dutch) about multiple SD libraries, huh? Is probably rigth, but I see no relation to "lwip". When reverting to lwip variant "Prebuilt Source" the error is gone! So using that for now ;-) |
|
Hi, Thanks for joining this wonderfull topic ;-) I'm the guy with the major errors using "lwip variant V2". Errors were gone when I switched to "Prebuilt source (gcc)". Gave updating lwip2 using your recipe a try but it runs into an error. Tell me if I made a stupid mistake, and I'll try again. BTW : I'm on a Mac. |
|
It's the
|
|
@d-a-v Removed the space temporarily, and tried again.
Here's the output: |
|
It's because you are not in latest master.
So either you pull and synchronize lwip2 subrepo, but it is easier to
modify lwipopts.h in lwip-git/ dir.
…--
on mobile
|
|
Maybe you can remove all the esp8266 dir and make a clean install from git repo. @d-a-v Thanks for the suggestion, I am now compiling with the MSS modification, I keep you updated :) |
|
I am now disconnected immediatly from the server: With MSS to 1200 it seems to work, but after a while I am disconnected too. |
|
With some debugs (with MSS defined to 1460): |
|
+1 for the Pratchett header in the server response! Anyway, I've been tweaking the ICY and HTTP readers. They can now automatically reconnect on 0-byte reads a user-specified number of times. Last night I had about 2.5hrs streaming before it couldn't reconnect (and at that point there was a internet or server issue because it tried 3 times over the span of 3 seconds to reconnect before giving up). @armSeb and @gerardwr , I'd suggest pulling the changes and adding a "file->SetReconnect(3, 500)" before you start a stream to enable it. To avoid the issue of LWIP settings, you may want to try using the GIT I've got (by sheer luck) for the Arduino core. I couldn't tell you what LWIP it's running, only that it works and my only change has been addition of the HTTPS server pull request (3001 in the Arduino repo). @d-a-v Forgive my TCP ignorance, but for some reason my Master's networking all involved ATM and its ilk, not TCP. If MSS = 600 and I do a http.read (1000) will I get a short read each time, or will it recombine multiple segments before sending it back to me? The algorithm can try combining multiple reads on short reads, but doesn't now, as before the max segment was >> than any MP3 or ADTS frame. |
|
I think the MSS=536 is a bad setting, as it forces the router to fragment packets and causes several latencies. I guess that the socket buffer re-assemble all chunks. Keeping MSS to 1460 seems (in my opinion) to be the best choice. |
|
@d-a-v Playing MP3 stream with MSS=536 was not working for me with "decoding errors" every sec, better with MSS=1460, but most of the time the streaming stops ("Mp3 done") within several seconds. When using variant "Prebuild source (gcc)" an Mp3 stream plays for "hours" without interruption. |
Final question : Sometimes the former version stopped streaming with "MP3 done" after some hours. Should I expect the latest version to play "forever"? |
|
@earlephilhower Excellent! |
|
Great news. If there are no network hiccups greater than (retries * delay) it should play indefinitely. For me, I think I'm on the wrong side of the Atlantic for the streamer I was using and did have real disconnects lasting > 1.5 seconds every few hours, but there's nothing to be done for that, really. |
|
I'm really happy with the library playing my favorite Mp3 stream all day, too bad that the AAC stream has artefacts :-( (ref. issue #12). Many thanks for sharing the library and the provided support. |
|
Hello, With the improved code I am now able to play the 48000Hz stream: http://icecast.omroep.nl/radio1-bb-mp3 |
|
I replied earlier that the latest repo performed worse, but I deleted this reply because accidentily tested with a 80Mhz CPU i.o. 160Mhz. Installed the latest repo, and tested the 48kHz MP3 stream : Stream runs but has quite some disturbances like "speckles". Maybe due to a temporary stream issue, as I got "reconnects after a while. Will try again later. |
|
I ran the 48K stream overnight, was still running this morning :-) so seems "bulletproof". But the sream is still spoiled by the continuous "speckles", as if as motorcycle with a bad ignition coil is running nearby. Restarted the ESP, but the speckles remain. Sometimes the ESP resets, but the stream is resumed automagically. |
|
Just to make sure, with the latest the 48K Radio1 stream has "speckles" BUT the Morow 44K MP3 stream is absolutely clean. Nice! |
|
Any reason to keep this open? I think we're tracking all the other things in other active issues. |
|
Agreed, have closed this issue now. |
This looks like an excellent library to stream internet-radio.
The StreamMP3FromHTTP sketch compiles (Arduino 1.8.1 and ESP8266 2.3.0), but with dozens of "red" warnings.
Upload to a Wemos D1 Mini (160Mhz)results in the errors below.
Any suggestions what to do?
The text was updated successfully, but these errors were encountered: