* 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

# audio latency

From your comment and the original "An update on Android's audio latency" article, there seems to be 2 different ways to calculate "audio latency".

* 1. play a well-known sound (a tone), listen for it in real-time

IIUC, the exact operation of this would be something like this:

  open recorder
  loop:
    timestamp1 <- getclock()
    play audio file 
    keep listening to input frames until detecting audio file signature
    timestamp2 <- getclock()
    sample := timestamp2 - timestamp1

Operation should be as follows:

  open recorder
  play audio file
  loop:
    keep listening to input frames for 1-2 seconds
  # analyze captured file
  look for 2x consecutive appearances of the original audio file
  sample := timestamp2 - timestamp1

# downlink/uplink latency

Many of the latency measurements break the latency down between audio downlink and uplink.

Q2: How is this measured?

The android doc discusses using a GPIO to have a zero-latency signal. You swap the signal on a well-known GPIO, and then play a well-known audio file. You then connect the GPIO to a speaker, and measure the latency between the GPIO-fed speaker, and the actual device speaker. As an optimization, you plug both the GPIO and the audio jack that feeds the actual device speaker into an oscilloscope, and get the distance there. Is this how audio downlink latency is measured?

Q3: If this is how downlink latency is measured, how do you implement it in prod devices (no access to the board)? Is this something that can be simulated using the usb-c plug?

# tools

The android doc/some googling points to several tools. I found oboetester, splatency, drrickorang, and google walt. I tested all but the walt one.

The first interesting thing is that oboetest, drrickorang, and walt seem to need an external jack-based dongle.

Q3: Why is this needed for? The audio latency approaches mentioned above should only need a speaker and a mic.

The experience has not been great for any of the tools. Operationally, I'd like to script these tests. Instead, I need to click on GUIs. Also, all the tools I tested seem to fail often, so I have to repeat the experiments multiple times. Also, I miss better documentation on exactly what they do.

Thanks for any help

edit: s/markdown/formatdoc/g

<1993: there's a bank in the middle. If the student cannot pay, the bank has to do the paperwork to get paid by the Feds. Note that the profit for the bank is limited.

>1993: no bank in the middle. University gets paid right away. Zero risk for them

The performance effects of QUIC implementing congestion control in userland are more interesting. OTOH, QUIC allows deploying new features to users (through cronet) in an efficient way. TCP does not.

[1] https://chromium.googlesource.com/chromium/src/net/+/master/...

> [Disclaimer: I've worked with some of the people who wrote BBR and QUIC, so I'm biased.] Ditto

Other languages also allow exporting to other formats. I use md-to-pdf all the time, and it works well. Integrating the use of other tools in the export process should be independent of the usage of emacs.

IIUC, what org-mode provides you is:

1. a (markdown-like) lightweight document markup language, with lots of syntax hooks ("#+") for different tools.

2. some (even lighter, i.e., no "#+" required) organization-based syntax hooks. These are the TODO/DONE/... labels (plus the "[ ]" tidbits), the table syntax, the metadata (e.g. AUTHOR). In fact, the idea of adding metadata to a lightweight markup language is very interesting.

3. some "programmy" syntax items, including things like tags, spreadsheet-like tables, properties, etc.

4. the agenda view. This is a horizontal search on multiple .org files to create a work agenda.

5. some emacs functionality related to automatic recognition and operation on some of the syntax items. For example, org-table-align will "Re-align the table and don't move to another field".

There are lots of other features, but nothing that other lightweight markup languages don't/can't have too.

My main concerns are:

1. it is inextricably tied to emacs. AFAICT, only (5) in the previous list is emacs-only. All the other functionalities are related to the markup syntax.

2. I wish the org-mode language was fully markdown compatible (I can barely remember the syntax of one, and now I need to use 2).

[0] http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pd...