After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 524724 - [PATCH] [baseaudiosrc] buffer-time and latency-time do not reflect actual values
[PATCH] [baseaudiosrc] buffer-time and latency-time do not reflect actual values
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.18
Other Linux
: Normal normal
: 0.10.20
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-27 22:24 UTC by Mark Nauwelaerts
Modified: 2008-05-31 18:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible patch (if applicable) (558 bytes, patch)
2008-03-27 22:25 UTC, Mark Nauwelaerts
none Details | Review
Patch for additional actual properties (4.06 KB, patch)
2008-05-28 19:46 UTC, Mark Nauwelaerts
committed Details | Review

Description Mark Nauwelaerts 2008-03-27 22:24:01 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.
Comment 1 Mark Nauwelaerts 2008-03-27 22:25:04 UTC
Created attachment 108148 [details] [review]
Possible patch (if applicable)

* Make latency-time and buffer-time reflect actual values in use.
Comment 2 Mark Nauwelaerts 2008-05-14 21:12:12 UTC
Is there an objection against committing this, so that these properties would correspond to reality ?
Comment 3 Wim Taymans 2008-05-14 21:15:26 UTC
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?
Comment 4 Mark Nauwelaerts 2008-05-14 21:35:41 UTC
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).
Comment 5 Mark Nauwelaerts 2008-05-28 19:46:40 UTC
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.
Comment 6 Mark Nauwelaerts 2008-05-31 18:15:25 UTC
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.