GNOME Bugzilla – Bug 680917
audiosinks: Inconsistent notify::volume emitting between Linux & Mac OS X audio sinks
Last modified: 2018-11-03 11:21:55 UTC
Created attachment 219994 [details] minimal testcase to reproduce, compiles on both platforms I found that there is inconsistent behavior of the notify::volume signal in the playbin2 object between OS X and Linux. For better explanation, I could create a reproducible minimal test-case which is attached and compiles on both platforms. On OS X, the callback in the test-case is never called, hence no output. Same program run on Linux will have the callback called twice. Note, that no volume is changed by the program at all. On Linux the notify::volume signal is called upon playback start, but not on OS X. I don't know what is correct behavior here, but there should be a consistent one, same on all platforms: Either have notify::volume triggered once upon playback start, or don't have it started but only on real volume changes. I would vote for having the notify::volume signal emitted upon playback start - we have used it in banshee which works fine on Linux to set the GUI volume information upon playback start. But this resulted in a bug when running banshee on OS X (thats how I found this bug, see banshee's bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=660012). Tested systems were an Ubuntu 12.04 with shipped gstreamer (0.10.36), and OS X Lion with compiled gstreamer 0.10.36 from source, using stock compiler on both plattforms.
I think that the bug needs one more test result: the one from running on a Linux system with no pulseaudio running (i.e. with alsasink as the default sink). This way we'll know whether the bug is Mac OS X specific or reproducible in all configurations where playbin2 exposes a software-based volume element.
I've removed pulseaudio on my ubuntu 12.04 machine (via "sudo apt-get autoremove pulseaudio") and re-run the test-case. This is the output I got: Cannot connect to server socket err = No such file or directory Cannot connect to server socket jack server is not running or cannot be started Volume got changed! So, without pulseaudio and using alsa the callback gets called once (compared to twice with pulseaudio). But it gets called, into contrast to OS X. So i think the OS X port needs fixing.
I think it's going to be very hard to make sure everything behaves exactly the same in this respect on any platform. Not sure it's worth going to great extents to make sure notify is only emitted once at the beginning rather than twice or somesuch. It will also depend a bit on the capability of the backends/audiosinks, eg. whether they have a stream-volume that can be non-1.0 on startup etc. etc. If you want to make the osx audiosink emit a notify on the "volume" property, that'd probably be ok (assuming there is one). If you want to make playbin (old playbin2) emit a notify on startup irrespective of the sink, that would be ok too IMHO.
Question is: why is it a problem if you get one or two or three notifications on startup?
It is not important that is only fires once , but is it important that it *at least* fires once on all platforms (but it doesn't on mac os x) or does not fire at all (upon pipeline setup) on all platforms. If the backend playbin sets the volume (maybe from a hardware mixer, or operating system volume level) on setup, notify::volume is the best way to i.e. adjust any application GUI volume control slider to that level. Maybe there are other ways, like to wait until the pipeline is setup up, poll for the volume and then refresh the GUI, but most likely the GUI-volume adjusting code has to be triggered by notify::volume callback anyways. I think more people will have the idea of putting that code into a notify::volume callback, and when they find that it works on linux they will move on, assume they did use the API correctly. The hours of debugging comes later, when they (or someone else) try to port it to another platform and wonder why it is not working. That is at least what happened to me when porting Banshee over to OS X.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/70.