Prior to this change, the UI thread was consuming approx. 10-14% CPU
in the idle state, and appeared to be running in an endless loop.
After this change, the UI thread is measured at about 0.1% CPU. I'm
not sure what the current consumption impact is, but it's gotta be
a power saving, even if slim?
Following manual testing with the device after flashing this change,
the UI responsiveness and music playback does not appear to be
negatively affected. The UI actions that were tested were:
- Scrolling through items on the root menu
- Scrolling through settings
- Scrolling through All Tracks with long-press on the bottom of
the scroll wheel (Page Down) on a device with ~20k songs
- Repeatedly hitting 'next track'
- Forcing a DB update, and scrolling through All Tracks while
updating the database.
The device was configured with the following settings when tested:
- TTS enabled
- Wired headphones
- Bluetooth enabled but not connected
- No DB auto-update
- Playing music
Prior to this change, the UI thread was consuming approx. 10-14% CPU
in the idle state, and appeared to be running in an endless loop.
On a stock (v1.2.2) build, `tasks` reported:
```
→ tasks
name core free stack run time
IDLE1 1 1.0 KiB 99.6%
IDLE0 0 1.1 KiB 86.5%
ui any 10.1 KiB 13.7%
console_repl 1 5.6 KiB 0.5%
Tmr Svc any 1.4 KiB 0.0%
audio_dec any 19.4 KiB 0.0%
main 0 2.0 KiB 0.0%
lvglDraw any 2.9 KiB 0.0%
btController 0 2.1 KiB 0.0%
esp_timer 0 3.4 KiB 0.0%
BTC_TASK 1 2.6 KiB 0.0%
worker_1 any 30.1 KiB 0.0%
worker_3 any 5.7 KiB 0.0%
worker_2 any 29.5 KiB 0.0%
worker_0 any 25.7 KiB 0.0%
BTU_TASK 1 3.2 KiB 0.0%
hciT 1 1.5 KiB 0.0%
ipc0 0 1.0 KiB 0.0%
ipc1 1 1.0 KiB 0.0%
audio_conv any 3.4 KiB 0.0%
```
Following this change, the UI thread decreased from 13% in idle to
0.1% usage, as reported by `tasks`:
```
→ tasks
name core free stack run time
IDLE1 1 1.0 KiB 99.8%
IDLE0 0 1.1 KiB 99.4%
console_repl any 6.4 KiB 0.5%
ui any 10.1 KiB 0.1%
btController 0 2.1 KiB 0.0%
Tmr Svc any 1.4 KiB 0.0%
esp_timer 0 3.4 KiB 0.0%
audio_dec any 19.4 KiB 0.0%
ipc1 1 1.0 KiB 0.0%
ipc0 0 1.0 KiB 0.0%
hciT 1 1.5 KiB 0.0%
BTU_TASK 1 3.2 KiB 0.0%
worker_3 any 20.7 KiB 0.0%
worker_2 any 29.4 KiB 0.0%
BTC_TASK 1 2.5 KiB 0.0%
worker_1 any 30.1 KiB 0.0%
worker_0 any 5.7 KiB 0.0%
lvglDraw any 2.9 KiB 0.0%
main 0 2.0 KiB 0.0%
audio_conv any 3.4 KiB 0.0%
```
This change introduces the ability to enable or disable the spoken interface/TTS from the on-device settings, either via the UI or the Lua console. This closes out the implementation of issue #245.
The TTS setting is only visible in Display settings if voice samples are present in `/.tangara-tts/` on the SD card.
Playback of new TTS voice samples is inhibited when TTS is disabled. By default, the setting is enabled, as the device will only play back TTS voices if samples are present on disk.
If you need samples to test TTS on your device, feel free to grab the voice samples I have at https://codeberg.org/tursiae/tangara-tts-samples. There's about 80-85% coverage of the UI, with the remainder to be added soonish.
Reviewed-on: https://codeberg.org/cool-tech-zone/tangara-fw/pulls/251
Co-authored-by: Tursiae <git@tursiae.org>
Co-committed-by: Tursiae <git@tursiae.org>
Reported in issue #258.
As of v1.2.0, if /.tangara-tts/ samples are present on the SD card, and
>= 4 menu items with matching TTS samples are highlighted in the UI, and
no audio output (headphones or BT sink) is connected, the `tts::Player`'s
invocation of lambdas on the WorkerPool will result in worker task
exhaustion.
This is because we get stuck in state where the `drivers::PcmBuffer` is
not accepting any new samples, and the inner loop in `Player::decodeToSink`
that pushes to the output isn't checking to see whether playback was
cancelled. So the loop never terminates, and we consume that worker slot.
Repeat with another 3 menu items, and, hey, all four worker threads are
consumed with TTS that will not terminate until headphones/BT are connected.
When `CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS` is not set, the FreeRTOS
scheduler will not keep track of task runtime statistics, and the `tasks`
command on the console will show `nan%` for the usage.
This adds a recommendation for the user to enable the `...STATS` config in
their build, and also updates the guidance for `configUSE_TRACE_FACILITY`
to point at the supported `sdkconfig.local` configuration pathway, instead
of pointing at the `#define` that's deeper in the configuration stack.
Also, the sampling period is dropped from 2.5s to 10ms when the runtime
stats are not enabled; given that we're not measuring any usage, it's not worth
sleeping any longer than that. We might even be able to drop to zero?
cooljqln
ayumi
jacqueline
Wesley Ellis
Tursiae
ailurux
ailurux
Sam
Riley Inman
Caitlin McCann