Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Somewhat random crashing #6

Open
Thenicolaibulow opened this issue Jun 17, 2020 · 5 comments
Open

Somewhat random crashing #6

Thenicolaibulow opened this issue Jun 17, 2020 · 5 comments

Comments

@Thenicolaibulow
Copy link

Hi Jørgen,

As previously mentioned, it seems some of us are experiencing random crashing. Thus i figured it'd create a new issue, documenting my experience.

As you suggested i've disabled A-MPDU in my router. The other settings you mentioned (in the menuconfig and router) was already disabled in my case.

Whenever i experience a crash (luckily nowhere near as often as karimsad, more like every
10th minute - ignoring plain stuttering) i receive these logs over serial:


I (234974) SNAPCAST: Received wire message

I (234974) SNAPCAST: size : 3

I (234994) SNAPCAST: Received wire message

I (234994) SNAPCAST: size : 3

I (235014) SNAPCAST: Received wire message

I (235014) SNAPCAST: size : 3

Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x401091a7 PS : 0x00060330 A0 : 0x800981c8 A1 : 0x3ffef080
0x401091a7: dsp_i2s_task_handler at /Users/blab/esp/snapclient/components/dsp_processor/dsp_processor.c:170 (discriminator 1)

A2 : 0x00000000 A3 : 0x000084cb A4 : 0x000000b0 A5 : 0x00000000
A6 : 0x00000000 A7 : 0x00039368 A8 : 0x00000000 A9 : 0x3ffef060
A10 : 0x00005bca A11 : 0x3ffb007c A12 : 0x3ffe436c A13 : 0x3fff80a0
A14 : 0x00000000 A15 : 0x3ffddbcc SAR : 0x00000003 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4000c28c LEND : 0x4000c296 LCOUNT : 0x00000000

ELF file SHA256: 8191af69b511a1a305a7f139fe86e8e6c434725945805dd06026c7255405424c

Backtrace: 0x401091a4:0x3ffef080 0x400981c5:0x3fff82e0
0x401091a4: dsp_i2s_task_handler at /Users/blab/esp/snapclient/components/dsp_processor/dsp_processor.c:170 (discriminator 1)

0x400981c5: vPortTaskWrapper at /Users/blab/esp/esp-idf/components/freertos/xtensa/port.c:143

Rebooting...


'dsp_processor.c:170' seems to be your 16 -> 32 bit conversion?
Is it possible that the client, or maybe just the 16->32 bit, doesn't deal well with empty packages?

The thing is, my crashes usually happens, whenever the server stops outputting - mainly whenever a song is change, or just plain play/pause. Quite odd.

And also, as i mentioned, if of client is turned off, it tends to crash the other client instantly. - However, this only effects the esp-clients! My phone continues to play just fine.

Håber alt er vel.
/ Nicolai

@jorgenkraghjakobsen
Copy link
Owner

Good point
i am pipeing in soma fm 007 channel that never stops - but if I kill my audio source I reboot on the esp32 :-)

`(2389730) SNAPCAST: c2s: -1592431106 252791
I (2389730) SNAPCAST: s2c: 1592431105 787935
I (2389740) SNAPCAST: Current latency: 555052542232.427979ms

I (2390600) I2S: Chunk :960 185664 192384
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x400d8403 PS : 0x00060730 A0 : 0x8008e224 A1 : 0x3ffe7080
0x400d8403: dsp_i2s_task_handler at /home/jakobsen/esp/snapclint/build/../components/dsp_processor/dsp_processor.c:183 (discriminator 1)

A2 : 0x00000000 A3 : 0x0004b3e3 A4 : 0x00000090 A5 : 0x00000000
A6 : 0x00000000 A7 : 0x00247a48 A8 : 0x00000000 A9 : 0x3ffe7060
A10 : 0x0003a60f A11 : 0x3ffb11ac A12 : 0x3f80013c A13 : 0x3fff00a0
A14 : 0x00000000 A15 : 0x3f800130 SAR : 0x0000001f EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : `

Same place your setup crash

Try to change the wait time (20) in
audio = (uint8_t *)xRingbufferReceiveUpTo(s_ringbuf_i2s, &chunk_size,(portTickType) 20 ,960); // 200 ms timeout
to some thing longer
and we need to do a handler that take action on this time out - Good point but to late now :-)
Tak alt vel - kik forbi kontoret hvis du kan nå det inden uge 27 - alt tyder på at du skal ha et nyt esp32 modul på dit board. Vi har også noget nyt som du nok gerne på hvis du har overskud til det. /j

@CarlosDerSeher
Copy link

CarlosDerSeher commented Nov 16, 2020

Hello Jørgen
I also reboot my esp32 when killing the stream fed to snapfifo on the server. Also this happens when killing snapserver itself.

First problem seems to be solved by checking if

audio = (uint8_t *)xRingbufferReceiveUpTo(s_ringbuf_i2s, &chunk_size,(portTickType) 20 ,960);

returns NULL. By changing following check

if (chunk_size == 0)

to

if ((chunk_size == 0) || (audio == NULL))

esp32 reboots by killing input streams to snapfifo seem to go away afterwards. Second issue is a task for another evening I guess :)

Regards Karl

@CarlosDerSeher
Copy link

so I found the reason for crashing was returning from FreeRTOS Http Task. I uploaded my changes to my fork: https://github.com/carlosderseher/snapclient Have a look if you like. Still needs some more testing, but seems to work stable now, although I might try to rewrite stuff to use some kind of state machine in there, not exactly sure what's the way to go yet.

Regards
Karl

@jorgenkraghjakobsen
Copy link
Owner

Hi Karl
Yes - that part of the code has not been designed with other fall out then audio keep pumping :-)
I will have a look on you code and update. I do not spend much time on the project for now. Plan to get back on track in a couple of weeks /j

@CarlosDerSeher
Copy link

I didn't do much changes really, spare time is a precious good for me nowadays :) I hope to contribute, so we can get multiroom working some time though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants