Android no longer seems to generate the mysterious 2085978496000 timestamps, so we can run these tests on Android again.
Differential Revision: https://phabricator.services.mozilla.com/D9356
--HG--
extra : rebase_source : 2571912ad85c5dfba2cf565f27836a8e26e3739d
extra : histedit_source : 22e4c18feb2e7a258b68b7df1b85582e7ed2e318
One of the commented-out test cases is failing (bug 1495446), so temporarily log an info() statement until bug 1495446 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D9355
--HG--
extra : rebase_source : afae17d6862536cffb9d08429af788a3aaae26c0
extra : histedit_source : 7700e1a3eaa21a62b0da0bd2f9ebe7877bb2b161
The Windows clock drift allowance was originally added for Windows XP (in bug 979649). I removed it in https://hg.mozilla.org/mozilla-central/rev/a1f769e90937 but it appears Windows 7 has the same clock drift problem that XP had.
Differential Revision: https://phabricator.services.mozilla.com/D9354
--HG--
extra : rebase_source : b3171b2fed1da141e62e0344527bba2dfef6e81a
extra : histedit_source : 273376a88d60c5bf820deb91f8c5f91e00aba292
Allow AudioSinkWrapper to access MDSM's audio queue in order to know whether the audio source ended.
Differential Revision: https://phabricator.services.mozilla.com/D8031
--HG--
extra : moz-landing-system : lando
The gains passed to GainStereoToStereo() are applied on only one of the input channels.
Depends on D9213
Differential Revision: https://phabricator.services.mozilla.com/D9214
--HG--
extra : moz-landing-system : lando
Instead of creating a timer and then setting the timer's target, we can
determine the timer's target and pass it in directly when the timer is
created. This reordering of steps is slightly more efficient, since
SetTarget() is both a virtual call and requires locking, both of which
can be skipped if we know the target at timer creation time.
Why we would need this is unclear however. the destination texture should always be smaller than what comes out of the decoder.
Differential Revision: https://phabricator.services.mozilla.com/D8672
--HG--
extra : moz-landing-system : lando
We should not init the audio steam when the audio queue is marked as finished.
Differential Revision: https://phabricator.services.mozilla.com/D8031
--HG--
extra : moz-landing-system : lando
Implement a new method in MediaManager that enumerates audio output devices and looks up for a given sink id asynchronously.
Differential Revision: https://phabricator.services.mozilla.com/D5870
--HG--
extra : moz-landing-system : lando
MediaDevice is the core object for audio device enumeration. By adding AudioDeviceInfo every information of audio devices will be available. In this case device id will be available from the first enumeration and there is no need to enumerate multiple times to get that info.
Differential Revision: https://phabricator.services.mozilla.com/D5869
--HG--
extra : moz-landing-system : lando
We don't want to notify state changed frequently if the input stream is consist of
interleaving audible and inaudible blocks.
This situation is really common, especially when user is using OscillatorNode to produce
sound. Sending unnessary runnable frequently would cause performance debasing.
If the stream contains 10 interleaving samples and 5 of them are audible, others are
inaudible, user would tend to feel the stream is audible. Therefore, we have the loose
checking when stream is changing from inaudible to audible, but have strict checking when
streaming is changing from audible to inaudible. If the inaudible blocks continue over a
speicific time thersold, then we will think the steam as inaudible.
Differential Revision: https://phabricator.services.mozilla.com/D7823
--HG--
extra : moz-landing-system : lando