Good question, and no, we do not have that number yet. What the phone figures measure: the timer starts after the player object exists and stops when the first 80 ms chunk comes back from the runtime (prime pass + one step). On iOS the sample creates LinnetPlayer before the timer, and its AVAudioEngine is started in the constructor, so the output is already open. On Android the AudioTrack is built before the timer but play() is called on the first write, so that one is "opened for this request" minus the construction cost. Nothing after the first write is measured: no output latency of the audio stack, no "cold open" of the route.

Two things I can say without measuring. The 8 s figure in the player helpers is a cap on how much audio may be queued ahead, not a pre-fill: playback starts on the first chunk, so the chunking benefit is not lost in our own buffer. What sits on top is the platform's output latency, which we have not characterised per device and will not guess at here.

It is easy to add: the iOS player already schedules buffers with a .dataPlayedBack completion callback, so timestamping the first one gives request-to-first-played-back directly, and AudioTrack.getTimestamp does the same on Android. I will run both variants (route already open vs opened for the request) on the A15 and the Snapdragon 662 and post the numbers here and in the README.