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

Audio dropout before track change #1409

Closed
dublok opened this Issue Jan 22, 2016 · 6 comments

Comments

4 participants
@dublok
Contributor

dublok commented Jan 22, 2016

With the current develop version I have audio dropouts a few seconds before a track change. The dropout occurs exactly when mopidy calls PlaybackProvider.translate_uri.
In my backend PlaybackProvider.translate_uri blocks ~ 0.6 second for an internet access.

@jodal jodal added this to the v1.2 - Gapless and GStreamer 1.x milestone Jan 23, 2016

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 3, 2016

This is kinda expected, with the gapless changes the audio system does a blocking callback to get the next uri, so if you don't get the next track going before the audio buffers run out...

Main thing we can do for this is make the queue sizes bigger to give backend more time to get the next track going.

@dublok

This comment has been minimized.

Contributor

dublok commented Feb 6, 2016

What about making the call of change_track async and not blocking the audio system?

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 6, 2016

No, sadly not. It explicitly needs to be blocking as the GStreamer pipeline needs to have the next URI set before the about-to-finish signal callback returns. If it doesn't get set the pipeline will stop.

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 10, 2016

Thing we can do for this before 2.0 is basically just add a setting for the buffer time of the queue we have before the tee. I would say to leave it blank by default, so use gst defaults, and then let people running into this increase to buy slow backends enough time to get the next uri.

trygveaa added a commit to trygveaa/mopidy that referenced this issue Feb 13, 2016

audio: Add a config option for queue buffer size
It may help to increase this for users that are experiencing buffering
before track changes. Workaround for mopidy#1409.
@jodal

This comment has been minimized.

Member

jodal commented Feb 13, 2016

Fixed by PR #1442.

@jodal jodal closed this Feb 13, 2016

@dublok

This comment has been minimized.

Contributor

dublok commented Feb 23, 2016

The fix does not help. I still have the audio dropout before track change. If I increase the audio.buffer_time than the dropout is earlier (buffer_time=10000 -> dropout 10 seconds before end). With a large buffer_time I also get a dropout short after starting a new track from queue.

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