Skip to content
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

Make playbin buffer-size and buffer-duration configurable in mopidy/audio section #1950

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

dingo35
Copy link

@dingo35 dingo35 commented Dec 24, 2020

@codecov
Copy link

codecov bot commented Jan 3, 2021

Codecov Report

Merging #1950 (481daf0) into develop (7037d58) will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1950      +/-   ##
===========================================
+ Coverage    76.97%   77.01%   +0.03%     
===========================================
  Files           55       55              
  Lines         4713     4721       +8     
===========================================
+ Hits          3628     3636       +8     
  Misses        1085     1085              
Impacted Files Coverage Δ
mopidy/audio/actor.py 61.38% <100.00%> (+0.70%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7037d58...481daf0. Read the comment docs.

@dingo35
Copy link
Author

dingo35 commented Jan 11, 2021

Bump.

docs/config.rst Outdated
Comment on lines 194 to 195
A value of 0 seems to work fine, then the minimum buffer size seems to be
determined by min_buffer_duration.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this sentence is a bit confusing, especially since the default value isn't zero.

docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated
Sets the minimum buffer duration of the GStreamer playbin. If you experience
buffering/stuttering, it may help to increase this. If you experience latency
when changing tracks, lower this value.
A value of 0 seems can work fine, although we recommend a minimum value of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should change this:

A value of 0 seems can work fine

To something like:

A value of 0 can work fine

docs/config.rst Outdated Show resolved Hide resolved
Comment on lines +63 to +64
_audio_schema["min_buffer_size"] = Integer(optional=True, minimum=0)
_audio_schema["min_buffer_duration"] = Integer(optional=True, minimum=0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given our code doesn't make any attempt to modify these values dynamically, I think it's probably better if the existing convention is followed by removing min_ from the start of the setting names.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No mopidy doesnt modify these values; what is meant is that this buffer is to be filled fully to the value specified, before playing starts. So the larger this value, the larger the latency. The buffer itself might be larger, or not, only GStreamer devs would know, but that is IMHO not relevant here....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree these names should change and the min_ prefix removed.

docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved
@@ -16,6 +16,8 @@ mixer = software
mixer_volume =
output = autoaudiosink
buffer_time =
min_buffer_size =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set the default values here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -60,6 +60,8 @@
_audio_schema["output"] = String()
_audio_schema["visualizer"] = Deprecated()
_audio_schema["buffer_time"] = Integer(optional=True, minimum=1)
_audio_schema["min_buffer_size"] = Integer(optional=True, minimum=0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make these new configs non-optional, they don't work the same as buffer_time (which is truly optional because we want to fallback to GST's default).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved

Expects an integer 0 or higher.

Sets the minimum buffer size of the GStreamer playbin. If you experience
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a GStreamer documentation reference specifying these properties are minimums? As I understand it, these values directly map onto the max-size-bytes and max-size-time properties of the uridecode's internal queue2 element. These are the maximum amounts the queue will buffer before it blocks the source. FYI, the high/low watermark settings of the underlying queue are not adjustable on a playbin.

dingo35 and others added 7 commits January 11, 2021 15:14
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
Co-authored-by: Nick Steel <[email protected]>
@kingosticks
Copy link
Member

I've made suggestions to be more explicit about what these configs adjust, rather than hide Gstreamer-specific things which would normally be the correct approach. I am in two minds but I think this makes sense here since adjusting the watermarks is actually what we want to do but that is sadly not possible.

@kingosticks
Copy link
Member

FYI, you can use the "Add suggestion to batch" button to avoid a bunch of separate commits and wasted CI runtime.

@kingosticks kingosticks added A-audio Area: Audio layer C-enhancement Category: A PR with an enhancement or an issue with an enhancement proposal labels Jan 11, 2021
@kingosticks kingosticks added this to the Next feature release milestone Jan 11, 2021
@kingosticks
Copy link
Member

So if we could just expose these config options as they are and avoid renaming them. If you wanted to suggest any of them be zero I think you would need to clearer about what happens but then you are just documenting parts of GStreamer that even they don't document clearly. I'd still prefer wording that made it clear that fiddling with these configs is fiddling with GST-specific parameters and unless you know what you are doing you should leave them well alone.

And in regards to the original forum post. The fix for removing all latency when switching radio streams is to specify the radio streams to GStreamer as "live" streams. Doing so disables GStreamer's "stream buffering", which is the only solution to avoid the x seconds of clock time it takes to buffer x seconds worth of audio from certain HTTP streams. Unfortunately it's really not obvious when you should set live mode for a random given HTTP URI. We could revisit the idea of setting it for all HTTP streams that appear to be unseekable, but that is a different PR.

@djmattyg007
Copy link
Contributor

@dingo35 to confirm, do these settings affect regular song-based playback, or just playback of livestreams?

@kingosticks
Copy link
Member

Everything, except Spotify.

@dingo35
Copy link
Author

dingo35 commented Jan 12, 2021

And in regards to the original forum post. The fix for removing all latency when switching radio streams is to specify the radio streams to GStreamer as "live" streams. Doing so disables GStreamer's "stream buffering", which is the only solution to avoid the x seconds of clock time it takes to buffer x seconds worth of audio from certain HTTP streams. Unfortunately it's really not obvious when you should set live mode for a random given HTTP URI. We could revisit the idea of setting it for all HTTP streams that appear to be unseekable, but that is a different PR.

I understand that you would expect that, but I don't think that it's true:

  1. Setting "is_live" (by calling set_live(True)) does not change anything measurable in latency when playing live streams; that is probably the reason that it is always set False and is AFAIK never set to True anywhere in the Mopidy code;
  2. It makes sense that this doesn't change anything in latency. You need buffering because you don't want the playing to be interrupted because data is not there. You have two kinds of data sources, the ones you can read from start to end, either local or remote, which I will call "files", and the ones that are sent out continuously ("non seekable"), which I will call "streams". Note that by that definition streams are always live. I can't think of streams that are not live, but that might be my limitation of imagination.

Now for playing streams you cannot read ahead (as you can with files), so you will always need a bigger buffer (or the same) (as opposed to files.
So if there are any buffers you can disable when playing streams, you could disable those buffers anyway for playing files.

Now I must be wrong, because both the GStreamer docs and the Mopidy comments all say the opposite. Could you please tell me where my thinking is going wrong?

@kingosticks
Copy link
Member

Setting "is_live" (by calling set_live(True)) does not change anything measurable in latency when playing live streams; that is probably the reason that it is always set False and is AFAIK never set to True anywhere in the Mopidy code;

No. It just doesn't make any sense in the majority of cases. It is up to each backend to decide where it wants to use it. The latest version of Mopidy-Tunein uses live mode for some streams. If you are interested you can install it from pypi with pip (it's not available from APT yet).

@dingo35
Copy link
Author

dingo35 commented Jan 12, 2021

That surely is interesting, because I use the TuneIn plugin; it's hard to measure latency, because tune-in adds latency too, so it is hard to keep conditions comparable. I will try to do some profiling of the code to see whether there is actual improvement of latency.

But as you mentioned earlier, that is OT to this PR. Now I am losing track of all those repositories, I have accepted all your changes, so if you need me to do anything please let me know (but you'll have to spell it out, as much as I like the mopidy code I've come to hate your github/circleci/action/workflow environment....)

docs/config.rst Outdated Show resolved Hide resolved
docs/config.rst Outdated Show resolved Hide resolved
mopidy/audio/actor.py Outdated Show resolved Hide resolved
dingo35 and others added 4 commits January 14, 2021 14:19
@dingo35
Copy link
Author

dingo35 commented Jan 14, 2021

Well the "Add suggestion to batch" option is greyed out, so I had to commit all this stuff separately.

Seriously, all this button pressing and patch switching for 15 lines of code? And then a mailbox overflowing with all workflow shit...
"Sometimes a machine is more a handicap than a help."

@kingosticks
Copy link
Member

I don't know why it's greyed out, I only recently noticed it even existed. I added those "suggestions" in attempt to to make it easier/quicker. An alternative would be to make the changes in your editor and push that new commit to this branch - zero buttons pressed. I guess it's a personal preference what you would prefer. I hope you can appreciate we are all just trying to get stuff done here.

@schuenep
Copy link

@dingo35 @kingosticks Hi, any updates on this PR? I started only today to use mopidy inside Phoniebox. I too noticed the long delay before starting a live radio stream. It really is not so nice user-experience wise.
Nevertheless I am very thankful for the existence and maintenance of this project :)

@jodal jodal modified the milestones: v3.4.0, Next feature release Oct 29, 2023
@jodal jodal deleted the branch mopidy:main March 1, 2024 23:15
@jodal jodal closed this Mar 1, 2024
@jodal jodal reopened this Mar 1, 2024
@jodal jodal changed the base branch from develop to main March 1, 2024 23:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-audio Area: Audio layer C-enhancement Category: A PR with an enhancement or an issue with an enhancement proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants