[gstreamer-bugs] [Bug 609801] [volume] Use sample accurate property values if a controller is used
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Wed Feb 17 13:14:20 PST 2010
https://bugzilla.gnome.org/show_bug.cgi?id=609801
GStreamer | gst-plugins-base | git
--- Comment #12 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-02-17 21:14:16 UTC ---
Now more comments on the actual patch - it is nicely done. But honestly I don't
think we want to do it like this for audio. For video we can sync on each
frame. For audio we want to sync at a similar interval.
process_controlled_*
...
for (i = 0; i < num_samples; i++) {
for (j = 0; j < channels; j++) {
if (*mute) {
*data++ = 0;
} else {
gdouble val = *data * (*volume) + 0.5;
*data++ = (gint8) CLAMP (val, VOLUME_MIN_INT8, VOLUME_MAX_INT8);
}
}
volume++;
mute++;
}
lets at least move the "if (*mute)" check out of the channel loop. Otherwise
this is okay. Compared to the uncontrolled loops we have the overhead for
nested loops and interating over 3 arrays. In addition we have the overhead for
filling the 2 control value arrays all the time. SO the controller overhead is
larger than the actual operation.
I see the control-value array functionality more suitable for fetching the
control curse for display purposes in the UI.
in volume_before_transform:
* shouldn't the GstControlSource object be taken in e.g. volume_setup() - this
doesn't change while running.
* also filling the self->mutes/volumes with default values needs to be done
when the size has changes and not on every buffer.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list