-
Notifications
You must be signed in to change notification settings - Fork 685
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
base: main
Are you sure you want to change the base?
Conversation
…re/reduce-latency
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
Bump. |
docs/config.rst
Outdated
A value of 0 seems to work fine, then the minimum buffer size seems to be | ||
determined by min_buffer_duration. |
There was a problem hiding this comment.
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
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 |
There was a problem hiding this comment.
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
_audio_schema["min_buffer_size"] = Integer(optional=True, minimum=0) | ||
_audio_schema["min_buffer_duration"] = Integer(optional=True, minimum=0) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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....
There was a problem hiding this comment.
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.
@@ -16,6 +16,8 @@ mixer = software | |||
mixer_volume = | |||
output = autoaudiosink | |||
buffer_time = | |||
min_buffer_size = |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of https://github.com/mopidy/mopidy/pull/1950/files#r555993368
@@ -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) |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of https://github.com/mopidy/mopidy/pull/1950/files#r555993368
|
||
Expects an integer 0 or higher. | ||
|
||
Sets the minimum buffer size of the GStreamer playbin. If you experience |
There was a problem hiding this comment.
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.
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]>
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. |
FYI, you can use the "Add suggestion to batch" button to avoid a bunch of separate commits and wasted CI runtime. |
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. |
@dingo35 to confirm, do these settings affect regular song-based playback, or just playback of livestreams? |
Everything, except Spotify. |
I understand that you would expect that, but I don't think that it's true:
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. 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? |
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 |
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....) |
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]>
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... |
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. |
@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. |
See forum discussion https://discourse.mopidy.com/t/buffer-size-and-buffer-duration-configurable-where-to-post-my-patch/4591