New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volume level does not persist between tracks #886

Open
jkjwong opened this Issue Nov 4, 2014 · 22 comments

Comments

10 participants
@jkjwong

jkjwong commented Nov 4, 2014

Whenever I select a song in the playlist it always starts at 100% volume.

For example if I play a song and then set the volume to 30%. Skip the song or select another from the playlist, it still says 30% volume but it is in fact playing at 100%. If I hit + or - to change the volume it will set it to that value i.e. in this case 31% or 29%. Makes no difference if I set a default volume in the config file.

So basically using the software volume control is useless.

I'm using mopidy 0.19.4 with ncmpcpp on Mac OS X 10.10.

@jodal

This comment has been minimized.

Member

jodal commented Nov 4, 2014

I cannot reproduce with the software mixer. Which mixer are you using?

@jkjwong

This comment has been minimized.

jkjwong commented Nov 5, 2014

Software mixer too. Are you testing with ncmpcpp?

@jodal

This comment has been minimized.

Member

jodal commented Nov 5, 2014

Yes, I'm using ncmpcpp, not that the client used should affect this.

@jkjwong

This comment has been minimized.

jkjwong commented Nov 5, 2014

That's odd. I have the same issue on two different Mac machines.

The volume level percentage indicator will persist correctly, so best to ignore that. Best test is to lower the volume right down so it is just about audible and then skip a track. Is next track also barely audible or is it reset? I'm sure you've tested already but just making sure :)

I would be fine just sticking with the Mac volume controls and leaving MPD/mopidy at 100% however sometimes even on one bar of volume it is too loud through headphones.

I haven't yet tested regular MPD with ncmpcpp yet to see if I have the same problem there. Will try when I have a chance.

@jodal

This comment has been minimized.

Member

jodal commented Nov 6, 2014

When I think about it, there's an obvious difference between our setups here.

The GStreamer software mixer doesn't work identical on all systems, but may depend on the audio sink in use. For example, on my system running Linux and PulseAudio, the GStreamer pulsesink is used, and setting volume using the GStreamer software mixer actually adjusts the application's volume level in PulseAudio.

On most non-PulseAudio systems, for example OS X, I believe the volume is only being set internally in the GStreamer pipeline. If we tear down too much of this between two tracks, its volume state may be lost.

@adamcik Want to have a look at this?

@jodal jodal added this to the v0.19.5 - Bug fixes milestone Nov 6, 2014

@rodriguezsergio

This comment has been minimized.

rodriguezsergio commented Nov 11, 2014

👍 I am experiencing the same thing on our office's mac mini using the software mixer.

@mambocab

This comment has been minimized.

mambocab commented Nov 26, 2014

I just wanted to note that I have the same problem on OS X 10.9.5 and I'm happy to help someone debug. Oddly, the volume doesn't reset between each song, it seems.

@jodal jodal modified the milestones: v0.20 - Audio cleanup part 1, v0.19.5 - Bug fixes Dec 23, 2014

@adamcik

This comment has been minimized.

Member

adamcik commented Dec 23, 2014

Tried reproducing on my Ubuntu system without any luck. Using fakesink, pulsesink and alsasink. I also tried stop and start in addition to next track to test the tearing down to much issue.

Can probably still get this fixed, just harder when I can't test any fix we come up with :(

@adamcik adamcik modified the milestones: v0.21 - Audio cleanup part 2, v0.20 - Audio cleanup part 1 Dec 28, 2014

@sirMackk

This comment has been minimized.

sirMackk commented Dec 29, 2014

I'm having the same issue. Mopidy is running on an OSX machine, version 10.8.5 and using the software mixer along with autoaudiosink for the output. Every time the track changes, the volume shoots up to 100%. I've set the "mixer_volume" attribute to 15, but no dice. I'm using GMPC as the client. I've made due with setting the system's volume using sudo osascript -e "set Volume 2.5" (hope this helps others).

Not an osx guy, but I know some python and I've messed around with gstreamer before so I'll see if I can troubleshoot this issue in between work assignments.

Thanks for all the work ya'll put into this.

@fatg3erman

This comment has been minimized.

Contributor

fatg3erman commented Jan 4, 2015

Just to say same here (mopidy 0.19.5, OSX 10.10.1), also that mopidy doesn't emit event:volumeChanged via the HTTP API when this happens so it must be happening at a lower level.
[Edit] Although having just said that, mopidy.playback.getVolume() returns 100, so something somewhere within mopidy is aware of the mixer setting.

@rodriguezsergio

This comment has been minimized.

rodriguezsergio commented Jan 16, 2015

@adamcik I'd be happy to help test on my mac.

@willejs

This comment has been minimized.

willejs commented Jan 28, 2015

+1 having this issue too.

@jcass77

This comment has been minimized.

Member

jcass77 commented Feb 3, 2015

I've done a bit of debugging on this issue.

The problem arises when the next track starts to play, and the state is changed to GST_STATE_PLAYING. For some reason self._playbin.get_property('volume') always reverts to 1.0 as soon as the state changes.

(https://github.com/mopidy/mopidy/blob/1b8feefcdc3215f57f3ba982b5abe807cbe4a0fd/mopidy/audio/actor.py#L459-461).

I'm not sure how to manipulate the GStreamer pipeline as per @jodal's comments above to prevent this from happening on OS X, but pull request #958 contains a sample workaround in case anybody can come up with a cleaner implementation.

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 3, 2015

Any and all state changes, or just via GST_STATE_NULL? Also with https://github.com/adamcik/mopidy/tree/feature/implement-gapless I suspect that things will only reset when the playlist ends, so we could make sure to set it when we start playing and nothing else.

@mambocab

This comment has been minimized.

mambocab commented Feb 3, 2015

@adamcik In my experience, the volume resets on some of the gaps between tracks, not just playlists. (This is assuming that there's a one-to-one mapping between Spotify playlists and the playlists you're talking about.)

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 3, 2015

The gaps between tracks are going away with the branch I linked :-)

jodal added a commit that referenced this issue Feb 12, 2015

@dRaiser

This comment has been minimized.

dRaiser commented Feb 20, 2015

I actually have the same issue on Arch Linux. Built git version of mopidy with specified commit, but it still changes volume to 100% sometimes when track is changed.

@jcass77

This comment has been minimized.

Member

jcass77 commented Feb 22, 2015

@dRaiser does this happen on every track change or only for some types of tracks or playlists?

@dRaiser

This comment has been minimized.

dRaiser commented Feb 22, 2015

Well, I use mopidy for Spotify mostly and it's definitely Spotify tracks/playlist. However it's hard to narrow it down - it's rather common - I can try some testing and note which tracks triggers this behaviour.

ZenithDK added a commit to ZenithDK/mopidy that referenced this issue Feb 28, 2015

ZenithDK added a commit to ZenithDK/mopidy that referenced this issue Feb 28, 2015

ZenithDK added a commit to ZenithDK/mopidy that referenced this issue Feb 28, 2015

ZenithDK added a commit to ZenithDK/mopidy that referenced this issue Feb 28, 2015

@adamcik

This comment has been minimized.

Member

adamcik commented Dec 5, 2015

We should check if the workarounds related to this are still needed with gapless having landed.

@jodal jodal modified the milestones: v1.2 - Gapless and GStreamer 1.x, v2.1 - Audio cleanup 2 Dec 5, 2015

@dRaiser

This comment has been minimized.

dRaiser commented Dec 5, 2015

Works fine here in latest versions.

@jodal jodal modified the milestones: v1.2 - Gapless and GStreamer 1.x, v1.3 - The rest of v1.2 Jan 17, 2016

@jcass77

This comment has been minimized.

Member

jcass77 commented Jan 28, 2016

I can no longer reproduce this on Mac OS 10.11.2 and Mopidy 1.1.2.

The last reported version that this was still an issue for appears to pre 1.0.4? (https://github.com/nextbigsoundinc/Tunebot-2.0/issues/4). @adamcik, can you think of anything apart from gapless that may have resolved the issue?

If so then we can probably remove the workaround and close this?

@jodal jodal removed the 0 - Backlog label Mar 26, 2016

@jodal jodal modified the milestones: v2.1 - The rest of v2.0, v2.2 - The rest of v2.1 Oct 24, 2016

@jodal jodal removed this from the v2.2 milestone Apr 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment