google / walt Goto Github PK
View Code? Open in Web Editor NEWA device for measuring latency of physical sensors and outputs on phones and computers
License: Apache License 2.0
A device for measuring latency of physical sensors and outputs on phones and computers
License: Apache License 2.0
Details at "Header files not found trying to build for Android"
https://groups.google.com/forum/#!topic/walt-discuss/ikdJ83ZBDDM
When typing a number into the number picker using the keyboard and then pressing ok on the dialog the number doesn't get saved.
It does get saved if the enter button is first clicked on the keyboard or if the spinner is tapped.
This might be tricky, the text field seems to be somehow buffered by the keyboard.
This is so it's easy to record test results with a build number rather than having to go through the Android settings menus
Be great if we could publish measurements for other devices including iOS, Samsung, LG and Sony.
For audio output test to work well the volume level needs to be high.
Experiment with the following:
Would it be possible to add scroll latency testing also for Android phones and tablets?
I.e. when the app detects a scroll event, we could flip the screen from/to black/white.
So, by detecting the tap down event (as with tap latency), and then with the screen sensor detect the screen update, we should be able to quantify the scroll (start) latency as well.
For now the workaround is to run
cd <repo root>/android/WALT/app/src/main
ndk-build
before building in Android Studio
Currently the window looks like a vertical screen about 1/3 of the width of the chromebook screen. This may be related to the forced portrait orientation in the manifest.
Need to check if connected before trying to run the test.
Tested on Nvidia Shield K1 build MRA58K
Steps to repro
Expected result:
Actual result
i find some android phone's ACTION_DOWN p2k_dt is less than 10ms,
so could you give some sample data about the TAP TEST?
thank you.
Current hard coded threshold is fairly low and results in large difference depending on direction on devices with bright screens. The threshold is set on Teensy side.
Some phones (Spreadtrum reference design for instance) uses the "T" pin to detect jack presence.
Considering it is left floating in the schematic, on those devices, the jack plug is not detected.
Wiring a 100-Ohms resistor on the pin fixed the issue.
While cloning the whole app is a lot of work, simplified end to end mesaurements can be prformed with fairly small efforts. In most cases it would only need some python scripts operating a WALT connected to a computer while the DUT only interacts with WALTs sensors.
The app does not properly request permission to access the microphone causing it to crash on some devices and simply fail to detect audio on others.
This can be worked around by manually granting permission in the permissions section of Android's settings.
The actionbar question-mark icon currently does nothing. It should show a relevant tooltip with text to guide the user on how to conduct the test.
At the end of a series of measurements, check for clock drift and display a warning if it's too large.
It looks like the old way of sharing or sending attachments by writing a world readable file to some place like Documents folder is now deprecated. The new way of passing the permissions along via an intent was too magical for me to figure out in one day. Ideally we want the app to create a dedicated folder of it's own that would be world readable so that the log files can be accessed by any other app for viewing or sending. The log files should also have a timestamp as part of the file name.
This will reduce variability arising from different finger speeds on different runs.
The calculation shouldn't depend on finger speed but we do see some variability.
H
To be able to test our devices which doesn't have USB host, we are using pywalt bridge mode, and forward the mort using adb reverse.
This needed to change the IP in APK source code to 127.0.0.1
Doing this, we hit some clock issues.
Checking the drift, or forcing re-sync of clocks doesn't seem to raise anything. Latency is always around 120us.
This has been tested on an Android 5.1 phone, both in USB Host mode and adb reverse bridged mode.
USB host mode works properly, adb reverse bridged mode raises negative dt, all events are dropped because of this.
Sometimes we notice small abs(dt) like -20, but sometimes it looks like the dt is coming from previous tap.
For instance if we wait ~ 15s between two taps, we notice a ~15s dt.
Have you got some ideas on where to look at?
Just recurd a bunch of touch events and compare kernel timestamps with callback time.
We need to be able to change a bunch of settings that are currently hard-coded.
Some settings are
When a series of measurements is done it would be way more interesting to see a histogram rather than just a median. Maybe show a live one that gets updated with each rep.
If the WALT app opened due to the device being connected, then opened again in such a way that no new intent is created (such as from the recents menu), the app will request permission to access a (nonexistent) USB device. If "OK" is chosen, a crash occurs.
Be great if the WALT Android app could use AAudio for running tests since this is likely to have better performance in future.
2 feature requests:
The second audio engine is probably not using the fast mixer and measures much higher latency.
Workaround for now is to kill and restart the app.
Also known as warmup time or cold latency
There is an exception when first running the brightness curve test, and then the blink latency test.
player.c uses the clock struct assuming it was synchronized via USB. In order to make it work with on ARC++ where synchronization is via TCP we need to switch to returning time in nanoTime() reference (same as CLOCK _MONOTONIC). And do the adjustment to WALT time in Java land.
Love the WALT tool! Experienced some frustration with the Tap Latency functionality though, until I discovered that the WALT firmware wasn't actually getting any data from the Adafruit ADXL335 accelerometer board. The firmware only targets the pins for the on-board ADXL335 accelerometer; the Adafruit ADXL335 accelerometer board maps to different pins on the Teensy arduino processor.
I recommend one of two solutions. Either:
Thanks,
Jason
Expected: while test is not running, user can scroll the log up and down.
Actual: log is not scrollable.
Expected Output:
u
758108 11
758706 11
759308 11
.
.
.
end
Actual Output:
1737914 11
1739008 11
u
758108 11
758706 11
759308 11
.
.
.
end
A few data points from the end of the previous test are being reported in the next test. This bug does not appear the first time you run the brightness curve test, but on every test after that exactly 2 erroneous lines are printed before the beginning of the current test (marked with u
). This bug does not appear on ChromeOS with the tcp bridge setup, and it does not appear on Android with the usb hub/ethernet setup.
Might be related: when running the brightness curve test, and then running Diagnostics -> Reconnect, an error is printed:
Unable to communicate with WALT: Unexpected response from WALT. Expected "v", got ""
After users run a test they could be given the option to upload the results to a server (Firebase? GAE?) which would then display a filterable list of devices and measurements.
When plugging in a Teensy that is not programmed with the correct Arduino code, the android app starts and shows a blank screen for some 10 seconds.
It probably tries to sync clocks and doesn't get the expected replies.
If the app is opened without WALT connected, then WALT is plugged in and the app is chosen to handle this event, a crash occurs. I think this is because a second instance of the MainActivity is created in response to the Intent.
Currently the recording enqueue latency is not reported in final results has pretty high variance. Investigate if it's better to timestamp right after SetRecordState() in startRecording.
Also take a look at playback side for cold start, might also be better to timestamp after SetPlayState().
It'd be really great if WALT could be used on iOS devices as well. This would allow like-for-like comparison of various performance metrics.
It can take some 7ms for the display to go from black to white. It would be really good to see the shape of the brightness curve as a function of time.
Currently we also time the display transition based on a hard-coded threshold value (in arduino code). It's important to know where on the curve this threshold is for a particualar display.
Gray out/disable the button on the FrontPage, and when pressed, show a toast saying MIDI is not available on this device.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.