Improve TapLatencyAnalyzer to detect TAP and TONE peaks separately #2327
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Priyadharshini-commits
force-pushed
the
TapLatency
branch
from
d6fc766 to
2ad592a
Compare
|
Please fill the cla |
| armed = true; | ||
| } | ||
| sampleIndex++; | ||
| slow = slow + (level - slow) * slowCoefficient; // low pass filter |
There was a problem hiding this comment.
Fixed Indentation
| float lowThreshold = EDGE_THRESHOLD; | ||
| final float EDGE_THRESHOLD = 0.01f; // trigger threshold for tap | ||
| final float REARM_FRACTION = 0.3f; // fraction of last peak to rearm | ||
| final int MIN_TONE_DELAY = 2000; |
There was a problem hiding this comment.
samples between TAP and TONE (~45 ms) in milliseconds
There was a problem hiding this comment.
Many devices have much lower latency. I really don't like hardcoding something like this 2000 sample check. How does round trip latency look for your device? Maybe if that passes, we can just skip the tap to tone for your form factor
There was a problem hiding this comment.
The Round Trip Latency for our Device is 88-91ms.
Using the same logic of MIN_TONE_DELAY with a 2000-sample check, we observed an average latency of 116 ms over 10 tests on a Google Pixel device, and an average latency of 106 ms over 10 tests on a standard Android phone. We believe that this logic consistent and does not impact the latency calculations on other devices, ensuring reliable comparisons across platforms.
| } | ||
|
|
||
| if (tapDetected && !toneDetected && !armed && (sampleIndex - lastTapIndex) > MIN_TONE_DELAY) { | ||
| if ((fast > EDGE_THRESHOLD) && (fast > 1.5f * slow)) { |
There was a problem hiding this comment.
Where is this 1.5f from?
There was a problem hiding this comment.
After detecting a TAP, the code waits a bit (MIN_TONE_DELAY) for the tone generated by the speaker to appear.
But when the tone comes, it’s not as sharp as a finger tap — it’s more continuous or sinusoidal.
fast > 1.5×slow → definite transient change (tone or pulse)
It’s a stability guard — making sure the “tone peak” is real and not part of noise or reverberation.
If we have used fast > 2.0 * slow again, the tone might never be strong enough to pass the condition — you’d miss it entirely (which is what was happening earlier in your logs).
So,
TAP → fast > 2.0 * slow (strong transient)
TONE → fast > 1.5 * slow (milder but distinct increase).
This make sure that TONE appears and latency event been added.
|
Also go to extras -> external tap to try this on another device. The idea is that you can use one device to detect edges on other devices |
Priyadharshini-commits
force-pushed
the
TapLatency
branch
from
2ad592a to
20521e7
Compare
Signed-off-by: Priyadharshini S <priyadharshini.s@intel.com>
Priyadharshini-commits
force-pushed
the
TapLatency
branch
from
20521e7 to
213e94f
Compare
2 participants
Added Logic to improve the latency caluculation for fatcat device.