ESP-BOX status error -6

[alibukharai]

Hello, I'm currently engaged in a project where I've obtained the MP3 data via HTTPS. However, when played on ESP-BOX, an error occurs at the end, leading to an infinite loop that never terminates. I've attached the .mp3 file. Could you assist me with this issue? Please find the .mp3 file from my personal repository link Here are the log

[chmorgan]

Hmm.

I think this could be an issue reported a few months ago. The case is that the player doesn’t at present differentiate between running out of data and hitting invalid data.

How much data is the player consuming on each call? Even if the return value is ambiguous the audio player should be consuming the data as it drops invalid data, so it should stop.

Chris

On Tue, Dec 5, 2023 at 5:22 AM Ali Hassan Shah @.***> wrote:

Hello, I'm currently engaged in a project where I've obtained the MP3 data via HTTPS. However, when played on ESP-BOX, an error occurs at the end, leading to an infinite loop that never terminates. I've attached the .mp3 file. Could you assist me with this issue? Please find the .mp3 file from my personal repository link https://github.com/alibukharai/mp3file Here are the log error-6.png (view on web) https://github.com/chmorgan/esp-audio-player/assets/60029742/7bd0bce0-f84b-4233-b0f3-4a907e4c9c2d

— Reply to this email directly, view it on GitHub https://github.com/chmorgan/esp-audio-player/issues/10, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4ADZB4XENQESZZTIBXDYH3YWLAVCNFSM6AAAAABAHNVZW6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDKOBUGY4DAMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[alibukharai]

for a time being i have changed the flag from DECODE_STATUS_NO_DATA_CONTINUE to DECODE_STATUS_DONE here. It helps to control the problem to some extent

[chmorgan]

Is it really an infinite loop though? How much data is the player consuming on each call to the mp3 decoder? It may be consuming data but never finding an mp3 sync and taking a long time to consume the remainder of the file.

Also, is the mp3 owned by you? If we had a short test case file that would help drive a test for the condition.

On Tue, Dec 5, 2023 at 9:43 PM Ali Hassan Shah @.***> wrote:

for a time being i have changed the flag from DECODE_STATUS_NO_DATA_CONTINUE to DECODE_STATUS_DONE here https://github.com/chmorgan/esp-audio-player/blob/fcb709b8de2dc58fafed9a82d9c3b0ae5aa97c55/audio_mp3.cpp#L142C27-L142C27. It helps to control the problem to some extent

— Reply to this email directly, view it on GitHub https://github.com/chmorgan/esp-audio-player/issues/10#issuecomment-1841994826, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJH4AFKT6U3XFAZZPD5GODYH7LTNAVCNFSM6AAAAABAHNVZW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRHE4TIOBSGY . You are receiving this because you commented.Message ID: @.***>

[chmorgan]

@alibukharai can you see if main has resolved the issue? @espressif2022 has put in a fix for errors at eof that may resolve this issue.

[espressif2022]

@alibukharai can you see if main has resolved the issue? @espressif2022 has put in a fix for errors at eof that may resolve this issue.

I've told him about this PR, maybe you can close it now, we'll update the chatgpt project.

And now, when we are doing TTS, we wait for all the files to be downloaded, and then we will perform the playback, which will wait for a long time, do you have any suggestions?

[chmorgan]

@espressif2022 so fmemopen() came to mind as soon as I saw your msg. Are you downloading the file into ram? Using fmemopen would let the audio player remain unchanged and unaware of the source of the data, continuing to receive a FILE handle (assuming the download rate exceeded the playback consumption rate and you had enough ram to fit the file being downloaded).

Otherwise we could abstract out retrieving the next piece of data for playback and by default plug in wrappers that use a file handle. I think you'd end up in a similar spot in terms of when to start playback though, you'd want to avoid starting playback until you were pretty confident you'd finish receiving the audio data that you needed to maintain continuous playback.

This is assuming I'm following the issue clearly and the goal is to avoid having to wait to start playback until the whole file is received, which could introduce hundreds of milliseconds of latency that, if you could start playback sooner, could be removed.

Thoughts?

[espressif2022]

@espressif2022 so fmemopen() came to mind as soon as I saw your msg. Are you downloading the file into ram? Using fmemopen would let the audio player remain unchanged and unaware of the source of the data, continuing to receive a FILE handle (assuming the download rate exceeded the playback consumption rate and you had enough ram to fit the file being downloaded).

Otherwise we could abstract out retrieving the next piece of data for playback and by default plug in wrappers that use a file handle. I think you'd end up in a similar spot in terms of when to start playback though, you'd want to avoid starting playback until you were pretty confident you'd finish receiving the audio data that you needed to maintain continuous playback.

This is assuming I'm following the issue clearly and the goal is to avoid having to wait to start playback until the whole file is received, which could introduce hundreds of milliseconds of latency that, if you could start playback sooner, could be removed.

Thoughts?

Yeah, we can get the stream size in advance and handle it with fmemopen, I'll do a simple test first, Thanks!

[chmorgan]

Please reopen if you have any further questions @espressif2022!