For real-time applications performing voice conversation, it can be important to know the output pipeline's lag, case in point being wanting to not listen to their own audio output if they don't use an algorithm for detecting own-output on the real-time audio input stream while playing output.
The underlying information signal for this is already available from CPAL but currently not being used by rodio code; hence there is neither any rodio API surface for querying it.
How API surface exposing those timestamps from CPAL or API surface providing digests of them would likely be highly opinionated. My own patch for that information is Generative AI based and does not reflect a generic sense of what different scenarios than my own would want the API surface of it to be like:
- It's not a raw raw-timestamp passthrough API passing the timestamps from rodio,
- But one which provides a digest of accumulates stats when called.
- For every CPAL output callback, it subtracts the callback invocation timestamp from CPAL’s predicted device-playback timestamp, and keeps these as samples on a ring-buffer.
Which is highly opinionated.
It would be nice to have an equivalent catering to the overall desire for lag information based on CPAL's said timestamps, which closely fits the realtime considerations and preferences of this project about timing-related telemetery API.
Related
#597
For real-time applications performing voice conversation, it can be important to know the output pipeline's lag, case in point being wanting to not listen to their own audio output if they don't use an algorithm for detecting own-output on the real-time audio input stream while playing output.
The underlying information signal for this is already available from CPAL but currently not being used by rodio code; hence there is neither any rodio API surface for querying it.
How API surface exposing those timestamps from CPAL or API surface providing digests of them would likely be highly opinionated. My own patch for that information is Generative AI based and does not reflect a generic sense of what different scenarios than my own would want the API surface of it to be like:
Which is highly opinionated.
It would be nice to have an equivalent catering to the overall desire for lag information based on CPAL's said timestamps, which closely fits the realtime considerations and preferences of this project about timing-related telemetery API.
Related
#597