Open funkybob opened 10 years ago
Hi I just recently looked at the volume code, when @Manko10 had issues. All Nightingale does, is telling gstreamer to change the volume of the output pipe, as far as I remember. You are, however, not the only person hhaving problems like this. We were not able to isolate the issue up to this point.
When the volume is changed using Nightingale Slider (Clicking or through Wheel) everything works properly.
When it is changed using MediaKeys, it doesn't matter if it's from Nightingale's another window, what is focused etc., if I jump to the next or previous track (Either with MediaKeys or using the next/previous track button) or if I double-click a new Track on the player, the system volume is reset according to Nightingale's slider volume.
The problem doesn't happen when the track changes naturally (Queue). It also doesn't happen when you pause and then unpause a track.
Now all we need to do is find any code shared by the next/previous functions and double clicking on the library, and possibly compare with play/pause to rule out what works well.
@freaktechnik I mostly code for web so Nightingale seems quite "out of my league", but Forked and cloned to my machine already, and if you can point me out the branch and where in the folder structure this problem could be (Like, controllers, models, libraries... Maybe giving me a link to docs about it. Anything that gives me the smallest idea what I should be looking for and where, so I'm not as lost), I'd love to try finding this out.
@ellahn: I suspect this would be somewhere in components/mediacore/gstreamer, which is unfortunately a C++ component so it can use the gstreamer C libraries.
You can find documentation on most of Nightingale's internal API at http://developer.getnightingale.com. I'd also suggest looking at the XPCOM guide on http://developer.mozilla.org. For the gstreamer docs you'll have to search yourself, but they shouldn't be too hard to find. Our wiki (http://wiki.getnightingale.com) could contain helpful resources, too.
On branches: this mostly depends on what version of gstreamer you want to look at. I suggest looking at the gstreamer1.0 code, which is in the branch with the same name, as we will migrate to gst1.0 in the foreseeable future. If you'd rather look at the issue in gst0.10, sb-trunk-oldxul is your branch. If this is magically fixed when using a gst1.0 build, I'll add arch to the unrealiable distros ;).
Then you probably want to figure out the path of the volume stuff. The components/mediacore/gstreamer stuff inherits from components/mediacore/base. For the UI, you should find the binding (an xml element definition, see https://developer.mozilla.org/en-US/docs/XBL) in app/content/bindings, however the volume slider inherits from other bindings, so it's a bit scattered. If you see dataremotes, those are preferences (about:config) used as shared values between front and backend (view and model, in a sense).
After all that I suggest trying to build Nightingale. Our build documentation is pretty good.
The first thing I'd personally like to have is a unit test, that reliably fails for you. Unit tests can be written in JS (see all the tests for the gstreamer mediacore: https://github.com/nightingale-media-player/nightingale-hacking/tree/sb-trunk-oldxul/components/mediacore/gstreamer/test), so nothing new apart from the whole Nightingale API/XPCOM and the testharness. This will hopefully also prevent us from reintroducing this bug alter on.
EDIT: See also the brand new CONTRIBUTNG.md
If you have further questions or encounter problems along the way, just ask them here or on irc.mozilla.org #nightingale
@freaktechnik thanks a lot. :D
I'll take a look at it, let's hope I can be of some assistance to you guys, I really like Nightingale.
Although the volume slider in the UI doesn't change, the "global" volume on my machine is pushed up to about 75% at the start of EVERY track.
Version: Nightingale 1.12, Build 2432 (20130416004705)
Debian sid/jesse hybrid.