GNOME Bugzilla – Bug 524724
[PATCH] [baseaudiosrc] buffer-time and latency-time do not reflect actual values
Last modified: 2008-05-31 18:15:25 UTC
That is to say, the application/user can set buffer-time and latency-time (more or less) as desired. Later on, in gst_base_audio_src_setcaps, ringbuffer specs are initialized with these values, and eventually (typically) passed onto an element's _prepare (e.g. alsasrc, osssrc) which then (possibly heavily) adjusts these specs. Upon return to _set_caps, the ringbuffer's buffer-time and latency-time are recalculated to reflect these changes, but this is not propagated to the element-properties latency-time and buffer-time. This may very well be as intended (?), but it does leave these properties with values that have very little (if any) "real meaning". In particular, the "outside world" (application/user) is left with no clue as to what is actually happening, i.e. being used.
Created attachment 108148 [details] [review] Possible patch (if applicable) * Make latency-time and buffer-time reflect actual values in use.
Is there an objection against committing this, so that these properties would correspond to reality ?
My objection is that it effectively changes the behavour of the element when you set it back to NULL and PAUSED because then it'll use the values of a previous run to configure the device instead of the values (or close to) that were configured by the user. Maybe an actual-latency/buffertime that is readable when configured perhaps?
OK, that could indeed happen if the device changes its mind in between. So I'll put up a patch that introduces readable actual-latency/buffertime properties as you suggest (with default set to -1).
Created attachment 111683 [details] [review] Patch for additional actual properties * Provide readable actual-buffer-time and actual-latency-time that reflect the actual configured ringbuffer values. This also performs some more LOCK'ing in a few other places to protect the ringbuffer field for concurrent access (as should perhaps already be the case according to GstBaseAudioSrc declaration specs). Should fit the prescription and will commit in a few days, unless some objection.
2008-05-31 Mark Nauwelaerts <mnauw@users.sf.net> * gst-libs/gst/audio/gstbaseaudiosrc.c: (gst_base_audio_src_class_init), (gst_base_audio_src_dispose), (gst_base_audio_src_get_property), (gst_base_audio_src_setcaps), (gst_base_audio_src_change_state): Provide readable actual-buffer-time and actual-latency-time properties that reflect the configured ringbuffer values. Fixes #524724.