This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
`nsIAudioChannelAgent` was created a common interface for a usage of in both js and C++ before, now we have no any JS code would use `nsIAudioChannelAgent`, it's only used in C++ code.
Therefore, in a coming refactoring (bug1580662), we will remove `nsIAudioChannelAgent` and use `AudioChannelAgent` as the only interface. Here we can make these classes start to reference `AudioChannelAgent`, instead of `nsIAudioChannelAgent`.
Differential Revision: https://phabricator.services.mozilla.com/D45748
--HG--
extra : moz-landing-system : lando
After applying patch4, now we would pull the change from `AudioChannelService` everytime after starting the agent, so we don't need to rely on letting `NotifyStartedPlaying()` to modify the config and use it to update our state.
Differential Revision: https://phabricator.services.mozilla.com/D45753
--HG--
extra : moz-landing-system : lando
As we start audio capturing explicitly, we should also take responsibility to stop audio capturing when we don't need it.
We were hiding too many details on `AudioChannelAgent` before, which allow us hard to know who and where we handle audio capturing.
Differential Revision: https://phabricator.services.mozilla.com/D45752
--HG--
extra : moz-landing-system : lando
Instead of calling those callback functions seperately, we could provide a function to pull those changes at once after starting the agent.
In addition, `WindowXXXChanged` are callback functions of `nsIAudioChannelAgentCallback`, so they should only be called by `AudioChannelAgent`, to indicate receiving the change from `AudioChannelService`. We should not call them directly.
Differential Revision: https://phabricator.services.mozilla.com/D45751
--HG--
extra : moz-landing-system : lando
`nsIAudioChannelAgent` was created a common interface for a usage of in both js and C++ before, now we have no any JS code would use `nsIAudioChannelAgent`, it's only used in C++ code.
Therefore, in a coming refactoring (bug1580662), we will remove `nsIAudioChannelAgent` and use `AudioChannelAgent` as the only interface. Here we can make these classes start to reference `AudioChannelAgent`, instead of `nsIAudioChannelAgent`.
Differential Revision: https://phabricator.services.mozilla.com/D45748
--HG--
extra : moz-landing-system : lando
Our implementation modified the state, in addition to throwing the exception.
And the tests not only didn't test for this, but wouldn't have reached that
code anyway, due to the harness giving up as soon as anything failed.
Differential Revision: https://phabricator.services.mozilla.com/D46106
--HG--
extra : moz-landing-system : lando
Both of these files obviously use things from the newly-included
headers, but they were not including them prior to this point.
Differential Revision: https://phabricator.services.mozilla.com/D46632
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
This will permit implementation of JSPrincipals::write().
Differential Revision: https://phabricator.services.mozilla.com/D44604
--HG--
rename : dom/worklet/WorkletPrincipal.cpp => dom/worklet/WorkletPrincipals.cpp
rename : dom/worklet/WorkletPrincipal.h => dom/worklet/WorkletPrincipals.h
extra : moz-landing-system : lando
This is necessary to keep the invariant that once the setter returns, the reverb
is ready to process.
Differential Revision: https://phabricator.services.mozilla.com/D43476
--HG--
extra : moz-landing-system : lando
The nsAString overload of GetCallingLocation directly converts the
original source file name string into an nsAString. A number of
callers that want the source file name in an nsAString are calling the
nsACString overload of GetCallingLocation, then calling
NS_ConvertUTF8toUTF16. This results in an extra intermediate copy of
the original string data.
Differential Revision: https://phabricator.services.mozilla.com/D42727
--HG--
extra : moz-landing-system : lando
This removes the call to SetThreeDPointParameter which is no longer necessary
now that we're using AudioParams for position and orientation. Doing the
conversion can cause an assertion failure when the AudioParams have a scheduled
future value.
Differential Revision: https://phabricator.services.mozilla.com/D42023
--HG--
extra : moz-landing-system : lando
This is inherently large, because modifying these bits of DOMMediaStream and
MediaStreamTrack affects all consumers and producers of all DOMMediaStreams and
MediaStreamTracks.
Things are generally much simpler now.
Producers of tracks now create a MediaStream in the graph, add it to a
MediaStreamTrackSource subclass that takes ownership of it, and add the source
to a MediaStreamTrack. Should the producer need a DOMMediaStream it is now much
simpler to create as the only thing needed is the current window. The stream is
a rather simple wrapper around an array of MediaStreamTracks.
HTMLMediaElement is still not as straight forward as other consumers since it
consumes the DOMMediaStream directly, as opposed to a set of tracks.
The new MediaStreamRenderer helper class helps bridge the gap between this fact
and the new track-based MediaStreamGraph interface, as it needs to juggle
registering multiple audio tracks for audio output. This hooks into existing
HTMLMediaElement logic and brings a welcome simplification to all the glue
previously needed there.
Differential Revision: https://phabricator.services.mozilla.com/D37934
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Direct use of aInput buffers for ArrayBuffer elements is not possible in
general. aInput buffers are const because they may be used elsewhere but
ArrayBuffer elements may be modified by script. If necessary, it would be
possible to later add a mechanism to mix inputs directly into the ArrayBuffer,
but often no mixing is required.
Direct use of output ArrayBuffer elements would require DetachArrayBuffer to
ensure the elements are not modified by script, but that would require
creation of a new ArrayBuffer JS object on each call.
https://github.com/WebAudio/web-audio-api/issues/1932 tracks specification of
making output data available for reading (for downstream node input).
Differential Revision: https://phabricator.services.mozilla.com/D34837
--HG--
extra : moz-landing-system : lando
It is easier to make a span than an nsTArray.
This also clarifies that the output array lengths are not modified.
Depends on D34833
Differential Revision: https://phabricator.services.mozilla.com/D34834
--HG--
extra : moz-landing-system : lando
This will be used to release the AudioWorkletProcessor on the correct thread.
Depends on D34480
Differential Revision: https://phabricator.services.mozilla.com/D34481
--HG--
extra : moz-landing-system : lando
When Firefox is configured to resist fingerprinting, the latency figure returned
is the most commonly found on a particular OS.
For Android, I got data from [0], roughly copy/pasted the table into a file and
did:
```
cat file | cut -d $'\t' -f4 | grep "^[[:digit:]]" | cut -d ' ' -f 1 | sort -h
| uniq -c | sort -h
```
which indicated that 40ms was a good number for round trip latency (input to
output). Since this is for output latency only and the audio path
is roughly symmetrical in terms of duration, we report 20ms.
For OSX, 512 is always used with the default hardware in Firefox, with this
patch, it's always 512 regardless of the setup.
On Linux/Pulse, we use 25ms [1] always, and this is adjusted by PulseAudio. This
makes it always return 25ms.
On Windows, there is a wide variety of configurations, but it's common to be in
the ballpark of 80ms output (this is very empirical, by testing a bunch of
hardware over the years).
For other OSes, we use 2048 frames (adjusted to the sample-rate).
[0]: https://superpowered.com/latency
[1]: https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_pulse.c#725
Differential Revision: https://phabricator.services.mozilla.com/D37723
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
It's dead code, because AudioScheduledSourceNode is an abstract class and all
subclasses override WrapObject.
Differential Revision: https://phabricator.services.mozilla.com/D32202
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
When we suspend or resume the `AudioContext`, it should affect ALL media streams which belong to or are related to the `AudioNode` that are created by this `AudioContext`.
As `AudioNode::OutputParams()` can only return the connected AudioParams, it doesn't return the AudioParams which are belong to itself. That means we would miss to apply the suspend/resume operation for those streams, and it would cause imbalancing suspended count.
Therefore, we let `AudioNode` to keep the reference of all its AudioParam, and return them to `AudioContext` in order to do the operation for all streams.
Differential Revision: https://phabricator.services.mozilla.com/D28008
--HG--
extra : moz-landing-system : lando
This is split from the previous changeset since if we include dom/ the file size is too
large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27457
--HG--
extra : moz-landing-system : lando
There is no specified limit on the number of inputs or outputs, except that
the webidl parameter is unsigned long, but Gecko has an implementation-defined
limit.
Differential Revision: https://phabricator.services.mozilla.com/D25898
--HG--
extra : moz-landing-system : lando
Andreas Pehrson
Paul Adenot
alwu
shindli
Boris Zbarsky
Nathan Froyd
Geoff Brown
Karl Tomlinson
Eric Rahm
Mark Banner
Sylvestre Ledru
Andrew McCreight
Dan Minor
Jared Wein
Bogdan Tara
Nicholas Nethercote
Emilio Cobos Álvarez
Victor Porof
Oana Pop Rus
Cosmin Sabou
Valentin Millet
Jan-Ivar Bruaroey
Ciure Andrei
Andreea Pavel
Brian Grinstead
Léo Paquet
Csoregi Natalia
Narcis Beleuzu
Dorel Luca