2.0 KiB
TODO
-
analyze the (secondly or so) noise beeps in the mp3 playback
- introduced with this commit
- is it librubberband, my failure to feed it properly (buffer exhaustion), or sth else?
-
correct sampling rate of libmpg123 vs. 48000 Hz using librubberband
-
record accelero and write recording to file
-
set feedForDelay in musicFeedThread() in PlaybackEngine.cpp
- LOGI("feed %d silence samples", num_samples);
- set the sleep delay
- ideally, set the buf size
-
check playback buf size, and reduce buffer sizes
- LOGI("onAudioReady() frames=%d", frames);
-
reduce lib size, librubberband is 1.3 M (one .so file)
- maybe we are compiling too many source files
-
TODO: see Android.mk in librubberband and copy options from
LOCAL_CFLAGS
O> 16 KB paging for NDK libs
-
target SDK level 35
-
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.6factor after all (but verify this!)
-
minimum amplitude for accelero (avoid detecting e.g. when phone is lying flat and you hammer on the table)
-
filter away bad SQI areas of the signal (do not detect steps if we have bad SQI)
Nice-To
-
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.
-
nice-to nice-to: ramp up audio pipelines twice - once to collect params, another one to use those
Technical Debt
- remove duplication of
mp3file_open()inmp3file_open_fd() - malloc() nullptr result handling
Before release
- check librubberband license