Created attachment 220919 [details] [review]
update the volume from gtk volume widget back to the libbanshee backend upon track change

(note that although similiar, this bug is not related to recently reported bugs at https://bugzilla.gnome.org/show_bug.cgi?id=680917 and https://bugzilla.gnome.org/show_bug.cgi?id=660012)

There is an issue on OS X with the playback volume. One can change the volume with the volume widget slider and it works fine, while playing the CURRENT track. As soon as the track/stream changes, the volume resets to 1.0 (max value), but the slider in the volume widget remains at the old position.

From my investigation, i happens because the volume level on OS X is not backed by real hardware, but instead gstreamer uses a software volume mixer. This software volume mixer resets to 1.0 whenever on change the uri in the playbin object, which happens in bp_open () in the libbanshee backend each time a track is changed.

On Linux the bug doesn't occur, because the gstreamer pulseaudio and the alsa audiosink have its own mixer implementations: When using alsa, the volume widget in banshee changes the global PCM volume (it is changed for every other application, too). This volume is then restored (read out from the system driver/hardware) on next track playback. The pulseaudiosink does not save the volume level back to the driver/hardware, but pulseaudio provides its own application level mechanism to store and save the volume level, even across program restarts (if you change the banshee volume and close banshee, the previous volume is restored by pulseaudio, not by banshee code).

This volume "memory" is not present on OS X in osxaudiosink, so the attached patch sends the volume level that is selected in banshee's volume widget back to the gstreamer/libbanshee backend each time a track is changed.