Marat

You are right, and thanks for the pointer: .dataPlayedBack fires when the buffer has finished playing through the device, so the first callback is "first buffer fully played", not playback onset. I will report it under that name, and get the onset separately.

Onset, iOS: once the player node is running, its render clock gives the host time at which sample 0 left the node (playerTime(forNodeTime:) on lastRenderTime, extrapolated back to sample 0), plus AVAudioSession.outputLatency for the device path. Cross-check: the first .dataPlayedBack minus the first chunk's duration, which in Linnet is 50 ms, not 80: the first chunk is 720 samples shorter because the session compensates the decoder's delay (docs/streaming-contract.md). Android: AudioTrack.getTimestamp returns a (frame position, nanoTime) pair, and extrapolating to frame 0 gives the onset directly.

One correction to my previous comment, having re-read the player: the constructor activates the AVAudioSession (category playback, mode spokenAudio) and wires the engine, but engine.start() and node.play() run on the first write. So the iOS figures are "route configured, engine started for the request", not "output already open". The measurement will therefore have three columns per device: first chunk returned (what is published now), playback onset, and first buffer fully played; each in two rows: engine started on the request, and engine pre-started with a silent buffer played through the route. A15 and Snapdragon 662, numbers here and in the README.

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.