cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ghenry22 <>
Subject [GitHub] cordova-plugin-media pull request: Streaming & Background threadin...
Date Thu, 21 Jan 2016 09:00:32 GMT
Github user ghenry22 commented on the pull request:
    @purplecabbage I have added rate control when streaming from a URL using avplayer and
tested that it works.  However test case 19 still fails in the automated suite but I believe
that is due to the way media is loaded and the success evaluator on the test.
    To explain:
    When setting rate to 0.5 and listening to a file it is audibly slower than normal playback
    When setting rate to 2.0 and listening to a file it is audibly faster than normal playback
    So rate can be set and adjusted and does change playback rate.
    The problem with the test is it plays for 4 seconds and expects the playback position
to be >7 when playing at rate 2.  This is fine when using the old avaudioplayer implementation
as it will first download the entire file locally and then start paying immediately at rate
2, resulting in a final position generally around 8.
    When using avplayer though to stream properly we don't download the entire file in advance,
we only start streaming when play is pushed so we now have a variance that throws the test
out.  If the file is slow to load from the source server for some reason we have a larger
variance.  GIven only 4 seconds play time there is not enough time for the stream to start
buffering and play at 2x rate in order to reach the magic test passing number.  This is completely
normal and expected.
    If the length of the test run was extended to say 10 seconds you would find a lot less
variance as it allows some time to buffer.
    If the mp3 source file is hosted on a local http server on the same machine running the
emulator and tests it will also download almost instantly and pass the test. (I have tested
this scenario).
    To test rate you could potentially play for 4 seconds at rate 1 and then play for 4 seconds
at rate 2 and if the output of the second play is close to 2x the first play then you have
success.  Given that the tests are run one after the other they are likely to both have the
same buffering time which mostly rules that out as a variable.
    I am not sure how to rewrite the test to do this though.  If someone could help to rewrite
the test then all tests will pass and this PR can finally get merged which would be fantastic!

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message