.IndexOf of AudioSourceIdx now is very slow.

[hash6iron]

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.

[pschatzmann]

No changes from my side!

[hash6iron]

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.

[pschatzmann]

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

[hash6iron]

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]

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

[hash6iron]

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]

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.

[hash6iron]

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

[pschatzmann]

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.

[hash6iron]

@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

[clutch2sft]

** Address not found ** Your message wasn't delivered to ***@***.*** because the address couldn't be found, or is unable to receive mail. Learn more here: https://support.google.com/mail/?p=NoSuchUser The response was: The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. For more information, go to https://support.google.com/mail/?p=NoSuchUser

[hash6iron]

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

[pschatzmann]

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

[hash6iron]

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]

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

[hash6iron]

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

[pschatzmann]

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