News for hackers. Stuff that matters.
Re:An update on Android's audio latency by chemag on Thursday March 11, 2021 @01:02PM (#26426979)
Thanks Don and Phil for the great answer. Some further comments:

* I find interesting that you are getting better correlations when you add a well-known noise burst instead of a less chaotic signal (e.g. a tone or a chirp). In retrospect, it makes sense

* for the uplink/downlink breakup, I see in the Usage.md file in oboetester that you're isolating the downlink measurement with the tap-to-tone experiment. For this experiment, the doc suggests to use (a) the jack to avoid the speaker processing extra latency, and (b) a USB-MIDI input device to replace the touch screen latency (15-30 ms).

2 questions here:

* Q1: I assume that, if instead of the jack, you use a usb-c audio adapter accessory mode, there should be no extra latency either, right? (I'm using late pixel phones)

* Q2: which device are you using for the USB-MIDI input?

Thanks again!

edit: s/markdown/formatdoc/g

Re:An update on Android's audio latency by donturner on Monday March 15, 2021 @10:03AM (#26466199)
> * Q1: I assume that, if instead of the jack, you use a usb-c audio adapter accessory mode, there should be no extra latency either, right? (I'm using late pixel phones)

That's correct, by using either the 3.5mm jack, or USB-C adapter you won't incur any additional latency introduced by DSP to improve the speaker acoustics.

However, the USB path typically does have a few ms higher latency than the 3.5mm jack path.

> * Q2: which device are you using for the USB-MIDI input?

We've used a variety of devices and found the latency differences to be negligible. At the moment I test with an old AKAI LPK25.