Audio dropout before track change

[dublok]

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.

[adamcik]

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]

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

[adamcik]

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]

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.

[jodal]

Fixed by PR #1442.

[dublok]

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.