[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