Remove dependency on gi.GstAudio

[robcee]

Doing some exploratory work on issue #6, I noticed we're importing gi.repository.GstAudio. This requires installation and import of Gtk, Cairo and a bunch of other Gnome-related libs that may not be applicable on a headless device.

Looking deeper, it appears we're only using GstAudio.StreamVolume.convert_volume() method to convert between linear and cubic volumes. The actual implementation in GstAudio is pretty straightforward in this case:

case GST_STREAM_VOLUME_FORMAT_CUBIC:
      g_return_val_if_fail (val >= 0.0, 0.0);
      switch (to) {
        case GST_STREAM_VOLUME_FORMAT_LINEAR:
          return val * val * val;
        case GST_STREAM_VOLUME_FORMAT_CUBIC:
          return val;
        case GST_STREAM_VOLUME_FORMAT_DB:
          return 3.0 * 20.0 * log10 (val);
      }

and the reverse (Linear to Cubic):

case GST_STREAM_VOLUME_FORMAT_LINEAR:
      g_return_val_if_fail (val >= 0.0, 0.0);
      switch (to) {
        case GST_STREAM_VOLUME_FORMAT_LINEAR:
          return val;
        case GST_STREAM_VOLUME_FORMAT_CUBIC:
          return pow (val, 1 / 3.0);
        case GST_STREAM_VOLUME_FORMAT_DB:
          return 20.0 * log10 (val);
      }

I propose removing the dependency and imports, and implementing this directly.

source: https://github.com/jojva/gst-plugins-base/blob/master/gst-libs/gst/audio/streamvolume.c

edit: updated to include the reverse case.

[kingosticks]

Mopidy requires GStreamer which requires GObject Introspection for use in Python. Since gi.repository.GstAudio is always available to us, why re-implement this code?

[kingosticks]

I might remember this wrong but isn't the Cairo stuff a suggested package rather than an actual dependency?

[robcee]

you might be right, @kingosticks. I believe it was suggested only.

Still feels heavy to me to bring in the gi stuff into an extension that's only using it for some trivial math. It would make development easier on this extension. Nevertheless, it's the call of the maintainers and I defer to your expertise.

Feel free to close this.

[djmattyg007]

If it's a dependency of core Mopidy code, changing its status as a direct dependency in this codebase won't make a lot of difference.

You're definitely correct to be wary of unnecessary dependencies. Just this week there's been another example of where long dependency chains can create hidden risks:

https://www.theregister.com/2021/03/25/ruby_rails_code/

However, in this case it's likely fine.

If you've brought in suggested dependencies by accident, and want to prevent these kinds of accidents from occurring again in future, I recommend following this SuperUser answer:

https://superuser.com/a/615583

This assumes you're using a Debian-based system of course.

[robcee]

based on comments by @kingosticks and @djmattyg007 above, I'm closing this. WONTFIX.