Conversation
| - `required_lead_time_ms`: integer - minimum startup lead time in milliseconds (e.g., codec init, decode warmup, audio backend buffering, DAC latency). Measure this from server transmit time of the start/restart trigger message ([`stream/start`](#server--client-streamstart) or [`stream/clear`](#server--client-streamclear)) to the timestamp of the first subsequent audio chunk. | ||
| - `min_buffer_ms`: integer - requested minimum ongoing buffer duration in milliseconds during playback (primarily for live streams), used to absorb network jitter and continuous-playback pipeline delays. |
There was a problem hiding this comment.
I'm a bit conflicted on these being statically set in the hello message (I know the PR mentions we make this assumption). In ESPHome, the very first run has at least double the lead time whereas subsequent lead times are much shorter (though this depends on the exact configuration, so it's tricky). For the min buffer, this could easily change on a cell connection at various points in time depending on signal strength. This one seems a lot harder for the server to dynamically update with though if we even had some mechanism to update it.
Should we consider allowing the hello message to be sent again in the middle of a live connection to update values (this has also come up for devices that want to switch between allowing volume control from the server or not; e.g., you plug a VPE into an amp and want the amp to handle the reset so you disable volume control on the server.
| - For live streams, keep each player's minimum buffer duration at or above `min_buffer_ms` when possible, capped by the maximum buffer size advertised in `buffer_capacity`. | ||
| - For buffered streams, prefer filling each player's queue near `buffer_capacity` to maximize stability. | ||
| - `buffer_capacity` is a hard per-player byte limit; servers should not send data that would cause a player's queued compressed audio to exceed this limit. | ||
|
|
There was a problem hiding this comment.
What happens in a live stream when a new player joins an already active group and it has a much higher min_buffer_ms value? What if a player leaves a group and now the max min_buffer_ms is much lower?
2 participants
There were 2 major gaps in the
player@v1role this PR aims to solve:Both issues are resolved by adding
required_lead_time_msandmin_buffer_msto theplayer@v1_supportobject. The server is then responsible for ensuring that both constraints are respected.Network latency is factored into
required_lead_time_msandmin_buffer_msby the player, also allowing for high-latency clients (like a player on a mobile network).Limitations
Network latency is not measured and remains static throughout the lifetime of the connection.
While this is sufficient for almost all real-world scenarios, including mobile-network players, it is still a minor limitation.