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.

Sign up for GitHub

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

Jump to bottom

fix stuttering AAC SBR playback when PSRAM is available #280

Merged
merged 2 commits into from
Feb 13, 2022
Merged

fix stuttering AAC SBR playback when PSRAM is available #280

merged 2 commits into from
Feb 13, 2022

Conversation

seife
Copy link
Contributor

@seife seife commented Feb 13, 2022

No description provided.

@seife
aac_decoder: make sure data ends up in internal RAM
6bf4cd3 
The ESP-IDF core code actually uses PSRAM also for standard "malloc" &
friends if it is available and the allocation id bigger than a certain
threshold (4kB by default). To make sure that the AAC decoder buffers,
especially the m_PSInfoSBR end up in RAM, use low level allocator calls
to specify where to alloc stuff. This also gets rid of the "try malloc
RAM first, if this fails fall back to ps_malloc" code, which probably
did not do what was wanted anyway.
This fixes stuttering SBR playback for me, which was caused by
m_PSInfoSBR ending up in PSRAM unexpectedly.
@seife
AACDecoder_FreeBuffers: fix free of *m_pce
d7055b6 
It was allocated in one 16x chunk, so only freeing one chunk is enough
@schreibfaul1 schreibfaul1 merged commit cda882a into schreibfaul1:master Feb 13, 2022
@schreibfaul1
Copy link
Owner

Thanks for the contribution. The effect occurs when switching channels. That now appears to be effectively suppressed.
The patch -mfix-esp32-psram-cache-issue must then be removed in PlatformIO.
I will add the same fix to the MP3 decoder. Hope it helps there too :-)

@seife
Copy link
Contributor Author

seife commented Feb 13, 2022

For me it was always the case when playing SBR streams (like the radio ffh ac3 stream in the I2Saudio example).
This might be because I'm initializing PSram already before initializing the audio stuff.
I think only after PSRamInit() it will be used for "normal" malloc, but this might be wrong.
I did not notice the problem in MP3 yet (and have not looked at all at the MP3 decoder), but if you want to make sure something is not in PSRAM, then just using "malloc" is not enough, you need to use the low-level functions. That's what I have learnt investigating this issue :-)

@seife
Copy link
Contributor Author

seife commented Feb 13, 2022

One more thing: from what I have read, the -mfix-esp32-psram-cache-issue is still needed, without that one there is possible data corruption when psram is used (you read different data than what you have written). This is a hardware bug in the earlier revisions of the esp32 (I have not yet encountered a "later" revision, all of mine are "early", even though I bought some recently).

@seife
Copy link
Contributor Author

seife commented Feb 14, 2022

for MP3 see #283 ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@seife @schreibfaul1