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
Fix latency stream #1845
Fix latency stream #1845
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1845 +/- ##
===========================================
+ Coverage 82.2% 82.22% +0.01%
===========================================
Files 77 77
Lines 6334 6339 +5
===========================================
+ Hits 5207 5212 +5
Misses 1127 1127
Continue to review full report at Codecov.
|
This change affects all audio we get over http, including stuff we want buffered properly. |
hello, |
This fix would work great for things that are actually streaming, e.g. things you can't seek in. But say you have backend that is http based but lets you stream with HTTP ranges than you're breaking them with this. As such we need a way for backends to give a hint to audio system about if this is live or not. Currently we have two main ideas for this:
Basically this needs to be something the backends opt in to, not something on by default. Does this make more sense? |
#1608 is essentially the "same" problem, just a different GStreamer flag. |
Ok thank you for your answer ! I get it now (at least, I think so...) So Lib providers are free to set "live_stream", and the PlaybackProvider.change_track has the info (via track object) and passes it to the audio actor. The audio actor has a flag as well, and I kept the implementation but with the flag check. (maybe I should use gstreamer flags but I don"t see how download flag work with streams ??) (from #1608) I didn't get how to use the Ref objects, because there is no way to recover the Ref object from change track ? |
Hello, @adamcik, What do you think of this implementation ? Is that what you meant ? Would you consider merging ? And would you consider merging for the 3.0.0 release if we reach the quality required ? Thank you ! |
Indeed this is along the lines of what I was thinking, main thing perhaps @jodal or @kingosticks could also chime in on is naming and having the state in the model vs asking the playback provider? Even though these are probably bikesheds.
I can't think of any strong reasons for one over the other, so if nobody else has objections I would have no problem with going with this as is.
We don't want to test with real streams. The tests should run quickly. Is there not a way to mock what you want? |
Yeah it looks a bad idea. I wanted to test the new section in _on_source_setup, inside |
This is all I can think of for now, what do you think ? |
Looks good to me. Feel free to add a changelog entry in the audio section of v3.0.0 in docs/changelog.rst
.
Co-Authored-By: Stein Magnus Jodal <stein.magnus@jodal.no>
Co-Authored-By: Stein Magnus Jodal <stein.magnus@jodal.no>
Co-Authored-By: Stein Magnus Jodal <stein.magnus@jodal.no>
Co-Authored-By: Stein Magnus Jodal <stein.magnus@jodal.no>
Co-Authored-By: Stein Magnus Jodal <stein.magnus@jodal.no>
Thanks! I've squashed and merged this in commit d3c1824. |
Thanks for this addition. Using the HTTP RPC API, how would one benefit from this when calling Looks like there's something missing and would love to give it a try if you have some ideas |
providing a fix for big latency when reading streams from web.
the fix comes from here:
https://discourse.mopidy.com/t/streaming-radio-station-pausing-buffering/1251/19