Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

Hi @pschatzmann
I have noticed that .IndexOf of AudioSourceIdxSDMMC now is very slow. I was using this in previous versions of AudioTools to search the index of a filename playing mp3 with Player. But now, ESP32 is freezed during a few seconds until IndexOf finish.

Any idea? Thanks in advance.

You must be logged in to vote

No changes from my side!

Replies: 6 comments · 11 replies

Comment options

No changes from my side!

You must be logged in to vote
0 replies
Answer selected by pschatzmann
Comment options

Hi @pschatzmann again.

it seems a problem with mp3 decoder, with FLAC and WAV is ok. Is there any changes in Helix MP3 decoder since August? i noticed that player not responding well when MP3 are playing.

I try to detect where is the error. I´m going to disable metada filter and check again.

You must be logged in to vote
5 replies
@pschatzmann
Comment options

Why don't you just look at the commit history on Github ?

@hash6iron
Comment options

I´m not sure where is the point of the change because I have not update for a long time ago because I wanted to fix library a concretly version where my project works fine, but I was to change file management to SD_MMC to support FLAC and I just detected the problem with MP3 now.

@pschatzmann
Comment options

Maybe that's the issue that you did not update the mp3 libhelix decoder ?

@hash6iron
Comment options

I observe that player begins to play file and something happend in parallel. Only occur with MP3 files but not with FLAC or WAV, The audio player function in my case is the same for these three kind of files.

@hash6iron
Comment options

Maybe that's the issue that you did not update the mp3 libhelix decoder ?

Yes, I updated all. I did a full clean and download all dependencies.

Comment options

I´m going to install v.9.0 of library.
https://github.com/pschatzmann/arduino-libhelix.git#v.9.0

You must be logged in to vote
1 reply
@pschatzmann
Comment options

With git you could move to any point of time w/o having to reinstall anything...
I am not aware of any changes from my side which would have this impact.

Comment options

@pschatzmann ,

With this version (see below) of audio-tools MP3 and player works fine. Then something happend with player and MP3Helix in the lastest version, but FLAC not playing and I back to have the problem with sampling rate transfer then I neither can't use this version, then only I can wait for a new version.

https://github.com/pschatzmann/arduino-audio-tools/releases/tag/v1.1.3

You must be logged in to vote
0 replies
Comment options

You must be logged in to vote
0 replies
Comment options

Hi @pschatzmann .

I see that metadatafilter provoque in decoder some breaks, but I have tried to disable it and player continues freezing the ESP32 with MP3 files playing.

[I] I2SCodecStream.h : 95 - virtual void audio_tools::I2SCodecStream::setAudioInfo(audio_tools::AudioInfo)
[I] AudioTypes.h : 127 - out: sample_rate: 44100 / channels: 2 / bits_per_sample: 16
[I] I2SStream.h : 96 - virtual void audio_tools::I2SStream::setAudioInfo(audio_tools::AudioInfo)
[I] AudioTypes.h : 127 - out: sample_rate: 44100 / channels: 2 / bits_per_sample: 16
[I] AudioPlayer.h : 259 - sample_rate: 44100
[I] AudioPlayer.h : 260 - bits_per_sample: 16
[I] AudioPlayer.h : 261 - channels: 2
[I] AudioTypes.h : 127 - out: sample_rate: 44100 / channels: 2 / bits_per_sample: 16

Counting delayed time from first PLAY.COPY until ESP32 defreezing.
Time is: 8.034s

[I] MetaDataFilter.h : 45 - write: 524288
[I] StreamCopy.h : 187 - StreamCopy::copy 524288 -> 524288 -> 524288 bytes - in 1 hops
[I] MetaDataFilter.h : 45 - write: 524288
[I] StreamCopy.h : 187 - StreamCopy::copy 524288 -> 524288 -> 524288 bytes - in 1 hops
[I] MetaDataFilter.h : 45 - write: 524288
[I] StreamCopy.h : 187 - StreamCopy::copy 524288 -> 524288 -> 524288 bytes - in 1 hops
[I] MetaDataFilter.h : 45 - write: 524288
[I] StreamCopy.h : 187 - StreamCopy::copy 524288 -> 524288 -> 524288 bytes - in 1 hops
[I] MetaDataFilter.h : 45 - write: 524288

You must be logged in to vote
5 replies
@pschatzmann
Comment options

Please provide a short reproducible example sketch with the offending mp3 file.
524288 is a crasy size!

@hash6iron
Comment options

Ok. Don´t worry by the file size, never was a problem, anyway occurs with all MP3 files, is not the problem the file.

@pschatzmann
Comment options

You would usually copy in 1k steps and not the whole file...

@hash6iron
Comment options

Ok. You are reason, the buffer size was the problem but, why in the previous versions there was not problem?

@pschatzmann
Comment options

Hmm, I don't know: To my knowledge there was no change to the MetaDataFilter logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.