Fixes for JEplayer #2445
Fixes for JEplayer #2445
Conversation
This enables jeplayer to allocate just one MP3File at startup, rather than have to make repeated large allocations while the application is running. The buffers have to be allocated their theoretical maximum, but that doesn't matter much as all the real-life MP3 files I checked needed that much allocation anyway.
After adding the ability to change files in an existing MP3File object, it became apparent that at the beginning of a track some part of an existing buffer was playing first. I noticed that in get_buffer, the just-populated buffer wasn't being returned, but the other one was. But still after fixing this, I heard wrong audio at the beginning of a track, so I took the heavy duty approach and zeroed the buffers out. That means there's a remaining bug to chase, which is merely hidden by the memset()s.
This lets a music player show it vu-meter style
|
Yes, I could, but it would ultimately be more finicky. There are a BUNCH of separate memory allocations, and writing a mini-allocator to make them come out of a passed in block didn't seem like a good use of time.
|
|
You don't need to allocate everything out of that block, you just need to allocate the things that are hard to reallocate. I'm wary of this change because it breaks the mental model of one MP3File per file. It'd be more of a MP3Decoder at that point. That may be ok but I feel like there may be a way to make the allocations more reliable instead. |
|
There are at least 5 allocations each bigger than 1kB, the biggest is over 8kB. What threshold would you consider for being "hard to allocate"? |
|
fwiw in arudino, where of course it is a compile-time decision whether to use MP3 or not, they found it was reasonable to just statically allocate 1 playback object rather than do the allocations dynamically. |
This