I tested this locally using the most recent alpha build for OS X and while the icon does indicate that the sound is muted it is not. 

Please grab the latest alpha build from here and see if this issue is fixed:

https://live.gnome.org/SummerOfCode2012/Projects/TimoDoerr_Banshee_MacOSX#Get_latest_pre-build_alpha_.app-Bundle_for_Mac

I am keeping this open and assigning the problem to Timo so if the problem persists he can look at it as part of his GSoC project, at least to fix the icon issue and possibly also the reset to zero problem if it persists for you.

Created attachment 219909 [details] [review]
Fix muted volume button when starting banshee on OS X

The attached patch solves the issue. I found the reason for this issue to happen is that on OS X gstreamer does not re-use the system wide audio setting but uses a custom (gstreamer internal) volume meter. The value of this custom meter is not initialized, which is fixed by the patch.

Review of attachment 219909 [details] [review]:

::: libbanshee/banshee-player-pipeline.c
@@ +349,3 @@
         
+    // initially set the audio volume returned from the playbin element
+	g_object_get (G_OBJECT (player->playbin), "volume", &player->current_volume, NULL);

Shouldn't that be g_object_set ? Or the comment is wrong ?

No, its g_objet_get to retrieve the volume from the playbin object and write it to the player->current_volume field. The current_volume is not related to gstreamer but a mere helper field that is returned via bp_get_volume (which is the DllImport function used by the GUI to set the volume in the volume slider widget). 

I can reproduce similiar behaviour on my ubuntu vm machine: when you start banshee, the volume in the right upper corner is at level 0. But if you click on a track to play, the volume gets set (to the system audios mixer volume). 

With the patch applied, banshee set the correct volume (not in the gstreamer pipeline but in the GUI!) right after constructing the gstreamer pipeline, but without having a track played yet. At the time banshee has finished starting, the gstreamer pipeline has already finished setup (via bp_initialize_pipeline), so at this point the volume of the pipeline is already known, and thus the patch copies the volume to player->current_volume, so that the slider displays the right volume level.

Here comes the catch on OS X: Because of some other bug (which might be in gstreamer, I am still investigating that) the volume (read: player->current_volume) is not set correctly when starting to play a track, but always remains at level 0. This is just a displaying error - the volume in the pipeline is not really muted and you will here music playing. Its just that the slider volume is not updated when switching tracks. This is the behaviour described by the original bug reporter. The patch will also work around that, but also it does fix a real bug which is that banshee (on linux & OS X) always displays volume 0 right after start until one plays a track.

I am thinking however to change the patch not to retrieve & copy the volume manually, but simply call the bp_volume_changed_callback once after pipeline setup, which will do the same.

Created attachment 219980 [details] [review]
fix to the bug, better approach

call  the bp_volume_changed_callback once after pipeline setup for setting player->current_volume

I found out why the player->current_volume never gets changed on OS X - there is an inconstency with gstreamer not emiting the volume::notify event upon playback start on OS X. I've reported this as an gstreamer bug with a test-case here: https://bugzilla.gnome.org/show_bug.cgi?id=680917

Never the less, I think the patch should get applied anyways as it fixes the issue of a volume level 0 at banshee startup on both OS X and Linux.

Comment on attachment 219980 [details] [review]
fix to the bug, better approach

Committed, thanks for the patch and the explanations.

I misunderstood the first patch, but I'm blaming the late nights at GUADEC for that ;)

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.