2026-03-04 01:31:35 +01:00
|
|
|
## TODO
|
|
|
|
|
|
|
|
|
|
O> 16 KB paging for NDK libs
|
|
|
|
|
* target SDK level 35
|
|
|
|
|
|
2026-03-06 00:55:09 +01:00
|
|
|
* record the accelero and check why repeated fast beats result in occasional detection outages
|
|
|
|
|
- guess: the threshold gets pushed so high that the later beats are not detected properly
|
|
|
|
|
- maybe we need the `*0.6` factor after all (but verify this!)
|
|
|
|
|
|
|
|
|
|
* minimum amplitude for accelero (avoid detecting e.g. when phone is lying flat and you hammer on the table)
|
2026-03-04 01:31:35 +01:00
|
|
|
* filter away bad SQI areas of the signal (do not detect steps if we have bad SQI)
|
|
|
|
|
|
|
|
|
|
## Nice-To
|
2026-03-03 14:19:56 +01:00
|
|
|
* myband PlaybackEngine.cpp has latency management and other audio performance related features.
|
|
|
|
|
Check if the app can be improved (audio wise) by using that code instead.
|
|
|
|
|
|
|
|
|
|
* Sampling rate for accelerometer - do we need to measure actual sensor FPS, or is it stable 50 Hz?
|
|
|
|
|
|
|
|
|
|
* re-calculate IIR filter coefficients. probably not critical for 50 Hz vs. 60 Hz.
|
|
|
|
|
|
|
|
|
|
* re-visit sampling rate and channel count.
|
|
|
|
|
MixingPlayer currently forces both to 48000 and 2 respectively,
|
|
|
|
|
regardless of what Android says would be optimal.
|
