Previously we were doing it synchronously, which led to some odd looking
livelock stacktraces... we still don't have a consistent repro, but this
at least makes the stack when we mount a lot more predictable
It's currently quite limited (no stereo or sample rate conversion,
multiple messages clobber each other, only plays if music is playing),
but we're getting there!
This allows the audio pipeline to remain responsive even when the drain
buffer has completely filled. This in turn means that you now see the
track info in the 'now playing' screen change if the current track
changes whilst you are paused.
Since I was fucking around a lot in the audio processor anyway, I also
added mono->stereo expansion so that playing mono tracks on Bluetooth no
longer destroys your ears.
This also has the effect of breaking up the enormous 'updateIndexes'
method into one call per file, which means database updates also no
longer monopolise a single background task for their entire duration.
avg. time per new file is now <140ms for a completely fresh database,
which is pretty good i think!
This saves about 1ms per new track right now, but more importantly means
that minting a new track id is now a single atomic operation, rather
than being its own database write. This is a useful property that will
come in handy in a few commits time.
- Themes can be loaded from disk and built-in
- Themes can be selected in a new themes menu of the settings screen
- Some touch-ups to existing themes
- The saved theme is persisted in nvs
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/87
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
- 'main' doesn't need 12k of internal ram
- lvgl's draw task doesn't need that much either
- also lower the bg worker stack sizes whilst we're here, since they've got tons over headroom
ailurux
jacqueline