[pulseaudio-discuss] [PATCH] mention the sound card clock and system clock difference in libpulse docs
Georg Chini
georg at chini.tk
Sat Oct 21 10:58:34 UTC 2017
On 19.10.2017 20:22, Tanu Kaskinen wrote:
> ---
> src/pulse/def.h | 19 +++++++++++++------
> src/pulse/stream.h | 8 ++++++--
> 2 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/src/pulse/def.h b/src/pulse/def.h
> index 680bdc981..87b7dd40a 100644
> --- a/src/pulse/def.h
> +++ b/src/pulse/def.h
> @@ -641,8 +641,8 @@ typedef enum pa_subscription_event_type {
> * pa_stream_update_timing_info() and pa_stream_get_timing_info(). The
> * total output latency a sample that is written with
> * pa_stream_write() takes to be played may be estimated by
> - * sink_usec+buffer_usec+transport_usec. (where buffer_usec is defined
> - * as pa_bytes_to_usec(write_index-read_index)) The output buffer
> + * sink_usec+buffer_usec+transport_usec (where buffer_usec is defined
> + * as pa_bytes_to_usec(write_index-read_index)). The output buffer
> * which buffer_usec relates to may be manipulated freely (with
> * pa_stream_write()'s seek argument, pa_stream_flush() and friends),
> * the buffers sink_usec and source_usec relate to are first-in
> @@ -652,12 +652,19 @@ typedef enum pa_subscription_event_type {
> * source_usec+buffer_usec+transport_usec-sink_usec. (Take care of
> * sign issues!) When connected to a monitor source sink_usec contains
> * the latency of the owning sink. The two latency estimations
> - * described here are implemented in pa_stream_get_latency(). Please
> - * note that this structure can be extended as part of evolutionary
> - * API updates at any time in any new release.*/
> + * described here are implemented in pa_stream_get_latency().
> + *
> + * All time values are in the sound card clock domain, unless noted
> + * otherwise. The sound card clock usually runs at a slightly different
> + * rate than the system clock.
> + *
> + * Please note that this structure can be extended as part of evolutionary
> + * API updates at any time in any new release.
> + * */
> typedef struct pa_timing_info {
> struct timeval timestamp;
> - /**< The time when this timing info structure was current */
> + /**< The system clock time when this timing info structure was
> + * current. */
>
> int synchronized_clocks;
> /**< Non-zero if the local and the remote machine have
> diff --git a/src/pulse/stream.h b/src/pulse/stream.h
> index 5dfdee1a0..7b9ba98b9 100644
> --- a/src/pulse/stream.h
> +++ b/src/pulse/stream.h
> @@ -706,7 +706,9 @@ pa_operation* pa_stream_set_name(pa_stream *s, const char *name, pa_stream_succe
>
> /** Return the current playback/recording time. This is based on the
> * data in the timing info structure returned by
> - * pa_stream_get_timing_info().
> + * pa_stream_get_timing_info(). The returned time is in the sound card
> + * clock domain, which usually runs at a slightly different rate than
> + * the system clock.
> *
> * This function will usually only return new data if a timing info
> * update has been received. Only if timing interpolation has been
> @@ -738,7 +740,9 @@ pa_operation* pa_stream_set_name(pa_stream *s, const char *name, pa_stream_succe
> int pa_stream_get_time(pa_stream *s, pa_usec_t *r_usec);
>
> /** Determine the total stream latency. This function is based on
> - * pa_stream_get_time().
> + * pa_stream_get_time(). The returned time is in the sound card clock
> + * domain, which usually runs at a slightly different rate than the
> + * system clock.
> *
> * The latency is stored in \a *r_usec. In case the stream is a
> * monitoring stream the result can be negative, i.e. the captured
Looks good to me.
More information about the pulseaudio-discuss
mailing list