google / walt Goto Github PK

Details at "Header files not found trying to build for Android"
https://groups.google.com/forum/#!topic/walt-discuss/ikdJ83ZBDDM

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.

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.

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.

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().

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.

Need to check if connected before trying to run the test.

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:

• connect the Adafruit ADXL335 accelerometer pins to the same pins as the on-board ADXL335; this has the drawback of making those GPIO header pins unusable for anything else though.
• change the firmware so that the user can select one of the two options with only minimal effort. Attached is an update to the walt.ino file that uses a #define to select one of the two modes. This still requires the user to make the change and upload the correct firmware though, so perhaps there's a better solution, like storing both binary versions on the phone/tablet and allowing the user to select which one to upload, or something like that...

Thanks,
Jason

walt.txt

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.

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.

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.

For now the workaround is to run
cd <repo root>/android/WALT/app/src/main
ndk-build
before building in Android Studio

2 feature requests:

• Tap latency should show a numerical value for the average latency, without this you have to manually record the result of each tap and calculate the average latency yourself
• Also would be useful to show the sum of touch2kernel and kernel2java

Also known as warmup time or cold latency

This is so it's easy to record test results with a build number rather than having to go through the Android settings menus

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 ""

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.

Be great if we could publish measurements for other devices including iOS, Samsung, LG and Sony.

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.

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.

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.

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.

• Allows measuring at the very top of the screen.
• Potencially can be different from normal mode due to difference in graphics pipeline.

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.

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.

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?

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.

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.

There is an exception when first running the brightness curve test, and then the blink latency test.

We need to be able to change a bunch of settings that are currently hard-coded.

Some settings are

• Number of reps for each type of measurement
• Delays between measurements
• Thersholds for waht is condidered to be a "reasonable" reading

H

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.

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.

Gray out/disable the button on the FrontPage, and when pressed, show a toast saying MIDI is not available on this device.

For audio output test to work well the volume level needs to be high.
Experiment with the following:

• Increase WALT sensitivity to allow lover volume, check if it adds too much noise
• Automatically set volume to max before starting the test (might be limited by system)
• Check the volume level and alert if it's low

Be great if the WALT Android app could use AAudio for running tests since this is likely to have better performance in future.

Tested on Nvidia Shield K1 build MRA58K

Steps to repro

• Connect Android device to WALT
• Run app and tap 'Audio latency'
• Tap the microphone icon

Expected result:

• Input latency test is run

Actual result

• The following message is displayed: WARNING: No sound detected

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.

Just recurd a bunch of touch events and compare kernel timestamps with callback time.

Expected: while test is not running, user can scroll the log up and down.
Actual: log is not scrollable.

At the end of a series of measurements, check for clock drift and display a warning if it's too large.