| Age | Commit message (Collapse) | Author |
|---|
|
tjk/tangara-fw:update-reuse into main
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/174
Reviewed-by: cooljqln <cooljqln@noreply.codeberg.org>
|
|
This should help significantly with https://codeberg.org/cool-tech-zone/tangara-fw/issues/121, which seems to be caused by some SD cards being very picky about being the only SPI device on their bus.
Co-authored-by: ailurux <ailuruxx@gmail.com>
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/176
Co-authored-by: jacqueline <me@jacqueline.id.au>
Co-committed-by: jacqueline <me@jacqueline.id.au>
|
|
|
|
This replaces the previous system of a separate track and queue repeat, with a RepeatMode type with the following options and behaviours:
- OFF: No repeat, queue or track. When the current queue finishes, shuffled or otherwise, playback will stop.
- REPEAT_TRACK: The current track will loop indefinitely, unless next is explicitly called through some user action (ie using the next button in the now playing screen)
- REPEAT_QUEUE: The entire queue will repeat indefinitely. When shuffled is enabled this will repeat the queue with new combinations each cycle.
The repeat mode is persisted in non-volatile storage, so the behaviour will be consistent throughout restarts and queue replacements, and so the "queue repeat by default" use case can be met in this way.
In addition, I've made it work a little nicer when the queue runs out in the now playing screen, keeping the previously played track shown and playback can be continued by using the play button or by going to a previous song in the queue.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/126
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
|
|
|
|
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.
|
|
- 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>
|
|
Also power it down whilst we're locked. This saves about half a
milliamp.
|
|
Mostly for debugging, but also u can toggle fast charging off and on now
|
|
It's now a bit more responsive to stuff happening, gives you more information, and remembers your previously paired devices for faster switching between them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Have a squizzy and lemme know if any issues @cooljqln 🐝
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/80
Co-authored-by: ailurux <ailuruxx@gmail.com>
Co-committed-by: ailurux <ailuruxx@gmail.com>
|
|
|
|
These two changes (mostly the former) dramatically increase
responsiveness when doing database updates; previously we were suffering
from some nasty priority inversion.
afaict the underlying need to acquire_spi seems to be fixed? i.e. spi
bus acquisition is working properly. fingers heavily heavily crossed.
|
|
we should avoid doing bt state machine stuff from these callbacks, since
espressif calls us whilst holding a lock. ideally we should move all of
them to background threads, but we need to do a deep copy to safely move
a few of them
|
|
|
|
We default to the fast one, and do not try setting the charge rate bit
on older samd versions
|
|
|
|
|
|
This is a more accurate way of knowing which track is playing when, and
also simplifies a lot of fragile logic in audio_fsm
|
|
|
|
|
|
|
|
- Blank the display when locking to prevent burn-in
- Delay turning the display on until *exactly* after the first lvgl flush
- Init the display in the ui task to avoid blocking the rest of boot
|
|
|
|
meant control3.
|
|
for me please)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Includes refactoring nvs settings to be a bit less duplicated
|
|
|
|
|
|
We don't currently do anything with them, so need to wait for the lock
on the bt thread
|
|
|
|
i hate this janky-ass protocol
|
