Make no sense to say this is experimental and will change in 4.0.0 when we are already above 4.0.0.
This should be removed, or updated to say it will not be in x.0.0
disable only turns off ENABLE but doesn't set the init tracking that
nrfx uses. uninit hangs if ENABLE is off and is called because it
waits forever for TX to stop.
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 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.
It was intended that the `f.load_glyphs` line was fast and did most of
the work. However, it actually didn't, because it's necessary to pass
in a code point by number, not by string.
Additionally, a little light layer violation is needed to make the check
for missing characters fast. This used to be less important, as no
fonts had missing characters. However, it would take an appreciable
length of time on the Korean translation when failing to find hundreds
of different code points.
Testing performed: built
build-circuitplayground_express_displayio/autogen_display_resources.c with ko
translation before and after change. verified the file content was identical.
Time went from about 7s on my machine to way under 1 second.
