This will be helpful when delaying resumption of tracks until there is an AudioCallbackDriver.
The memory for the array is also transferred to the callee to save an allocation.
Differential Revision: https://phabricator.services.mozilla.com/D76801
Tracks remove themselves from the graph after DestroyImpl() and so should not
be added again after this.
These methods are now invoked only on the MediaTrack removing the possibility
of calling the wrong method.
Depends on D76797
Differential Revision: https://phabricator.services.mozilla.com/D76798
DestroyMediaTrack() is called only on Unlink or destruction of the AudioDestinationNode.
If there are no references to the AudioDestinationNode, then the graph's last stream
will be destroyed and the graph will shut down itself.
Differential Revision: https://phabricator.services.mozilla.com/D74812
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
This patch will do :
- replace the old pref with the new pref
The advantage of doing so :
- to ensure those tests can still use the correct blocking autoplay policy
Differential Revision: https://phabricator.services.mozilla.com/D73973
DestroyMediaTrack() is called only on Unlink or destruction of the AudioDestinationNode.
If there are no references to the AudioDestinationNode, then the graph's last stream
will be destroyed and the graph will shut down itself.
Differential Revision: https://phabricator.services.mozilla.com/D74812
CLOSED TREE
Backed out changeset f42150bdee2b (bug 1626772)
Backed out changeset ab5b637f714a (bug 1626772)
Backed out changeset fd4026a9f380 (bug 1626772)
To support checking CrossOriginIsolated in performance.now(), we need to:
- Add new types to TimerPrecisionType for nsRFPService
- System, HighResAllowed are added
- All is renamed to Normal
- Introduce a set of Reduce methods which require isSystemPrincipal and
CrossOriginIsolated to be passed and decide the TimerPrecisionType later
- Original Reduce methods should only be called when callsites know the
TimerPrecisionType. Otherwise, they should call the new methods.
- The following patches will use new methods
Differential Revision: https://phabricator.services.mozilla.com/D63293
--HG--
extra : moz-landing-system : lando
TRACE_AUDIO_CALLBACK() and TRACE_AUDIO_CALLBACK_COMMENT(aFmt, ...) log to a hardcoded thread id number. This creates confusion when more than one MTG is running because logs from different threads are depicted to the same thread line and overlapping each other. Those logging commands have been removed and the TRACE* command is used that it logs per thread-id.
Differential Revision: https://phabricator.services.mozilla.com/D69031
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Moving the trace point for messages to the inner loop allow understanding what
pages are doing better (if they are creating lots of nodes or changing lots of
params, etc.). Also, it is important to be able to characterize `onmessage`
calls.
Having two tracepoints under `ProcessBlockOnPorts` allows gauging the buffer
preparation overhead. vs just the page's processing code.
Differential Revision: https://phabricator.services.mozilla.com/D67464
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
Those are needed, respectively to be able to ensure the stream doesn't go away
when messaging back to the control thread, and then to access the details of the
exception thrown.
Differential Revision: https://phabricator.services.mozilla.com/D64765
--HG--
extra : moz-landing-system : lando
Having nested AutoJSAPI clobbers the exception value of the innermost one on
destruction.
Differential Revision: https://phabricator.services.mozilla.com/D64763
--HG--
extra : moz-landing-system : lando
In order to be able to change the audio output device, the device id is exposed to the constructor of MediaStreamGraph. Any component that gets/creates an MTG will be able to provide the device id in order to determine the desired output device. If the provided device id is null the default device will be used.
Differential Revision: https://phabricator.services.mozilla.com/D64133
--HG--
extra : moz-landing-system : lando
This keeps the worklet/graph thread alive for control and MessagePort messages
until there are no references to main thread objects.
In test_getUserMedia_audioCapture, the track of the OscillatorNode being
recorded does not end, and, even if it did, MediaRecorder would not listen for
ended notification on the node's track but its pipe track. Recording via
DestinationNode works around this because the DestinationNode track ends and
MediaRecorder listens to this track directly because it has
EXTERNAL_OUTPUT. Previously MediaRecorder would stop when the MediaTrackGraph
was shutdown, but this is no longer happening.
Depends on D65069
Differential Revision: https://phabricator.services.mozilla.com/D65070
--HG--
extra : moz-landing-system : lando
This will allow the node to drop its self reference without
AudioContext::Shutdown().
Depends on D65068
Differential Revision: https://phabricator.services.mozilla.com/D65069
--HG--
extra : moz-landing-system : lando
This will allow the class to be used from AudioDestinationNode.
Depends on D65067
Differential Revision: https://phabricator.services.mozilla.com/D65068
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
This converts `nsAutoPtr` usage in dom/media to `UniquePtr`. Beyond just a
search and replace we also needed to update assignment and access of the
`UniquePtr`s. This falls into a few categories:
- Assignment from a newly constructed object switches to `MakeUnique`
- Assignment from a raw ptr switches to `UniquePtr::reset`
- Handing out a raw ptr now requires `UniquePtr::get`
- Uses `UniquePtr::release` rather than `nsAutoPtr::forget`
- A few spots are updated to return a `UniquePtr` rather than a raw ptr
Differential Revision: https://phabricator.services.mozilla.com/D60084
--HG--
extra : moz-landing-system : lando
The change to throw NotSupportedError in AudioContext::CreateBuffer is
purposeful, to align with the spec and Chrome. There's apparently no web
platform test coverage for this, but we'll work on converting our test to a WPT.
The change to AudioContext::Close is fixing what looks like an obvious bug to
me (it _resolved_ a Promise<void> with a DOMException!). No obvious test coverage; https://bugzilla.mozilla.org/show_bug.cgi?id=1614960 tracks adding some.
The change to throw RangeError in OscillatorNode::Start is purposeful, to align
wih the spec and Chrome. Again, there's apparently no test coverage.
The change to throw RangeError in OscillatorNode::Stop is purposeful, to align
wih the spec and Chrome. Again, there's apparently no test coverage.
Differential Revision: https://phabricator.services.mozilla.com/D62141
--HG--
extra : moz-landing-system : lando
This is based on looking at what the actual spec constraints around the
channelCount, channelCountMode, and channelInterpretation setters are and on
testing Chrome's behavior: the setters _can_ be called as long as you do it with
the current value. That said, the spec sure could use being clearer here; the
style it's using is pretty hard to follow, unfortunately.
Differential Revision: https://phabricator.services.mozilla.com/D62140
--HG--
extra : moz-landing-system : lando
Please review the changes to Errors.msg very carefully. I caught a number of
mistakes there in self-review (e.g. not renumbering replacement markers
correctly when I added {0} to the beginnings of strings), and my confidence
that I caught them all is only middling.
A few lines (MSG_USELESS_SETTIMEOUT, MSG_TYPEDARRAY_IS_DETACHED,
MSG_NOT_SUBMIT_BUTTON) were removed from Errors.msg either because they were
already unused or because they either were single-user constant strings or
became such in the new setup and we could just use the string version of
ThrowTypeError.
Differential Revision: https://phabricator.services.mozilla.com/D61523
--HG--
extra : moz-landing-system : lando
This adds the name of the interface and method to the beginning of the exception
string when reporting the exception from Web IDL codegen, so it's clearer what
was called.
Some existing error messages are adjusted to not duplicate the information
about which method was called.
Differential Revision: https://phabricator.services.mozilla.com/D61521
--HG--
extra : moz-landing-system : lando
Now we support [AllowShared] in WebIDL, we don't need to manually check shareness
and throw exception if API don't accept SharedArrayBuffer, the binding will handle
it.
Differential Revision: https://phabricator.services.mozilla.com/D60001
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
This removes a level of indirection where the graph had to call back into
AudioContext. It also removes a dependency on the graph from GraphDriver, where
it can now just resolve a MozPromiseHolder instead.
Differential Revision: https://phabricator.services.mozilla.com/D56075
--HG--
extra : moz-landing-system : lando
and don't call process() on inactive AudioWorkletProcessor when inputs are null.
AudioNodeTrack::mIsActive, which determines when ProcessBlocksOnPorts() is
called, differs slightly from "actively processing" in the spec.
"An AudioScheduledSourceNode is actively processing if and only if it is
playing for at least part of the current rendering quantum" but
AudioNodeTrack::mIsActive is set even before the source node has started
playing.
Null input blocks provide a better indication of inputs that are not actively
processing.
Differential Revision: https://phabricator.services.mozilla.com/D54663
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
Move helper functions out from `AutoplayPolicy`, makes us clearly know which one could really be used to determine the blocking autoplay result. It also give other classes an ability to use those helper functions if they have a need.
Differential Revision: https://phabricator.services.mozilla.com/D52432
--HG--
extra : moz-landing-system : lando
This is in line with the meaning of channelCount in the Web Audio API
specification.
Differential Revision: https://phabricator.services.mozilla.com/D51864
--HG--
extra : moz-landing-system : lando
- Add a pref for controlling the batch size when doing webaudio decoding
on RDD.
- If batch size is greater than 1 and the decoder is capable of batch
decoding, send raw sample batches to decoder.
Differential Revision: https://phabricator.services.mozilla.com/D51454
--HG--
extra : moz-landing-system : lando
Stop using MediaFormatReader and use a demuxer and decoder directly in
MediaBufferDecoder. This will allow us to do batch decoding calls for
webaudio that will improve performance by reducing the number of IPC
calls to the RDD process.
Differential Revision: https://phabricator.services.mozilla.com/D51453
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
This reworks how media element captureStream works by removing the differences
between MediaStream and MediaDecoder capture. MediaDecoder capture will be
refactored so that ownership of MediaStreamTracks lies with the media element
instead of the OutputStreamManager. The internal MediaDecoder parts happen in a
later patch.
The new API for capturing a MediaDecoder involves a boolean on/off toggle, the
output tracks the decoder pipes data to, and the principal that data is tagged
with. If capturing is on but there are no output tracks, playback will not
happen, to ensure that no data gets accidentally skipped in the output tracks
while captured.
This also changes the logic for setting up MediaElementTrackSources in
HTMLMediaElement so it's triggered by the WatchManager and thus run in tail
dispatched runnables.
Differential Revision: https://phabricator.services.mozilla.com/D52040
--HG--
extra : moz-landing-system : lando
Stereo output is what the immense majority of mobile and desktop users have.
Differential Revision: https://phabricator.services.mozilla.com/D52693
--HG--
extra : moz-landing-system : lando
AudioNodeTrack::ProcessInput() uses ProcessBlock() when input and output
counts are <= 1.
Differential Revision: https://phabricator.services.mozilla.com/D50552
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
This completes my review of skipped Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D49954
--HG--
extra : moz-landing-system : lando
It's perfectly possible to create unstable filter, that can easily go to
infinity, so this assert is not valid.
Differential Revision: https://phabricator.services.mozilla.com/D49608
--HG--
extra : moz-landing-system : lando
WebAudio upmix layout is defined in the spec for the channel configurations mono, stereo, quad and 5.1. Layouts with 3 and 5 channels are not defined yet. For those undefined layouts firefox provided upmix to a single channel (left). This has been updated to upmix to the two stereo channels (left, right).
Differential Revision: https://phabricator.services.mozilla.com/D49610
--HG--
extra : moz-landing-system : lando
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
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
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
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