I caught this locally on Android, c.mDuration was 104517 (which is more than two
seconds at the rate it was), it was overflowing uint32_t because we want to do
this in integers so the multiplication is big. The alternative is to make the
computation in floating point, rounding up so that there's enough space in the
buffer.
Now I wonder why we have such a big segment sometimes, and only on some OSes, but
we can investigate this later.
Differential Revision: https://phabricator.services.mozilla.com/D138303
The returned value from AppendAndConsumeChunk is never used so there is
no need to return value from it.
Depends on D135248
Differential Revision: https://phabricator.services.mozilla.com/D135546
The interface for getting the data source of the AudioInputProcessing in
AudioInputTrack is moved from AudioInputProcessing::NotifyInputData to
::ProcessInput, which takes an AudioSegment forwarded from the
AudioInputTrack's source track
Depends on D131870
Differential Revision: https://phabricator.services.mozilla.com/D122513
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
[1]: https://searchfox.org/mozilla-central/rev/f351e19360729b351bfc7c1386d6e4ca4ea676e2/tools/clang-tidy/config.yaml#70
Differential Revision: https://phabricator.services.mozilla.com/D117714
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
Differential Revision: https://phabricator.services.mozilla.com/D117714
Add an utility function named AppendFromInterleavedBuffer in
AudioSegment to append data from the given interleaved buffer. This
function does the same job as what AudioInputProcessing::InsertInGraph
and NativeInputTrack::ProcessInput were used to do. As a result, these
two functions can be eliminated or simplified.
Depends on D116673
Differential Revision: https://phabricator.services.mozilla.com/D116674
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
By using the soundtouch library, this patch implements the time stretching on the samples in AudioDecoderInputTrack when its playback rate is not 1.0f, in order to support changing playback rate on the captured media stream.
As the time stretcher has to be initialized by a fixed channel count, we would perform a realtime up-mix/down-mix for those audio chunks which have different channel count thant AudioDecoderInputTrack's initial channel count.
Differential Revision: https://phabricator.services.mozilla.com/D114560
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
When an AudioCallbackDriver starts a fallback SystemClockDriver is running in
its stead. The AudioTrack getting fed data from the input stream of the driver
will get real data while the AudioCallbackDriver is running, and silence while
the fallback driver is running.
If the MediaStreamTrack representing the microphone source is part of a
MediaStream being played by an HTMLMediaElement; and another MediaStreamTrack
representing another source with a lower channel count than the microphone is
part of another MediaStream being played by another HTMLMediaElement; then:
1. We start the graph with the other source's output channel count, and a
fallback driver.
2. Once the audio driver has started, it adds data at a higher channel count
than the graph's to its MediaTrack. The driver switches audio driver to
match the new channel count.
3. The new driver starts with a fallback driver, which adds silence to the
track. Silence has no channel count, so the graph sees only the channel
count of the other source and switches audio driver to match this.
4. Go to 1.
This patch fixes makes us memoize a previously returned max channel count for an
AudioSegment for use when there is only null data (e.g., silence) present in the
segment. This applies to step 3 above, where no audio driver would be switched
because the graph still sees the mic's channel count.
Differential Revision: https://phabricator.services.mozilla.com/D95931
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
It is technically possible to have different channel count per chunk, so we
should reinitialize the resampler when that happens. This is a bit awkward
because the rates are on the track, but the data is in the chunks, and the track
cannot access the chunks, so we have to plumb the resampler state down.
Differential Revision: https://phabricator.services.mozilla.com/D53806
--HG--
extra : moz-landing-system : lando
It is now the max channel count of the underlying chunks or 0 if there are no
segment.
Differential Revision: https://phabricator.services.mozilla.com/D51865
--HG--
extra : moz-landing-system : lando
It's not maintained and probably does not work anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5438
--HG--
extra : rebase_source : ccd622e40844dda5d16266e49991462d4ea94224
Add method to help us know whether audio block is audible or not, so that we won't
show the sound indicator for silent web audio.
Differential Revision: https://phabricator.services.mozilla.com/D7819
--HG--
extra : moz-landing-system : lando
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This allows static analysis to pass for AudioNodeExternalInputStream.cpp.
MozReview-Commit-ID: 9dvllnnODed
--HG--
extra : rebase_source : 0c7665a3240422d52b82c5c2eaa4942be522dcb9