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
Implemented Rust/C++ glue code for rtcp-fb
Implemented parsing support for rtcpfb-wildcard in rust
Activated c++ unit tests
MozReview-Commit-ID: 5xRSQz7pucZ
--HG--
extra : rebase_source : 97fdfda9134197381d16e0a61dda5357bba9e9da
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 5f5154fc9fc7590cc02eb25146e5bc20b2243fa3
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 97f472f6ed1c5d6bed1af01fb7243a82b2629b03
We currently set the Android JavaVM pointer in MediaEngineWebRTC.
However, because of that, we end up setting the pointer in the child
process, even though we really want to set the pointer in the parent
process because that's where the camera will be accessed.
This patch makes us set JavaVM inside VideoEngine itself, where we
actually access the camera in the parent process.
MozReview-Commit-ID: 3TeLiiK2vyh
This removes the dispatch to the sts thread prior to calling
AudioConduit::InsertDTMFTone. There are assertions in ChannelProxy which
restrict the methods there to running on the main thread, so the current
code crashes immediately when inserting a tone in a debug build. The
inserted DTMF event ends up in a queue, so there is no reason not to just do
the insertion from the main thread.
MozReview-Commit-ID: G8JM9QDLrGF
--HG--
extra : rebase_source : 65168ee08efa5fc1960e35fd5acf4bdde0420b84
This allows removing locking, and allows other threads to progress without
taking the lock, hence lowering the probability that the lock will be taken for
a long time when we need to pull NeqEQ.
MozReview-Commit-ID: HMO67A0hher
--HG--
extra : rebase_source : aa5c77895eb57d60b61d9a8a5822e53593348830
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
This also causes a lot of dropouts. We don't need to lock here. NetEQ is thread
safe, and its created in the ctor. The rest of the members are made atomic or is
simply never accessed in multiple threads.
MozReview-Commit-ID: 2fRw5ZgxdpQ
--HG--
extra : rebase_source : f2aa082a3e856e873cfcd96ff721ccdc77df3633
This accounts for half of our audio dropouts, there is very high contention on
this piece of data.
MozReview-Commit-ID: 2HSfqZHT2MK
--HG--
extra : rebase_source : 10c451ac60563a0f1c14a314f5a12cc45055e20b
This allows removing locking, and allows other threads to progress without
taking the lock, hence lowering the probability that the lock will be taken for
a long time when we need to pull NeqEQ.
MozReview-Commit-ID: HMO67A0hher
--HG--
extra : rebase_source : aa5c77895eb57d60b61d9a8a5822e53593348830
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
This also causes a lot of dropouts. We don't need to lock here. NetEQ is thread
safe, and its created in the ctor. The rest of the members are made atomic or is
simply never accessed in multiple threads.
MozReview-Commit-ID: 2fRw5ZgxdpQ
--HG--
extra : rebase_source : f2aa082a3e856e873cfcd96ff721ccdc77df3633
This accounts for half of our audio dropouts, there is very high contention on
this piece of data.
MozReview-Commit-ID: 2HSfqZHT2MK
--HG--
extra : rebase_source : 10c451ac60563a0f1c14a314f5a12cc45055e20b
This hard codes the visual studio version to 2015. We did the same thing for the
gyp build. It also sets default paths for visual studio, which are ignored by the
remainder of the build system.
This was required to get gn code generation working on a fresh install of
Windows. I must have had similar changes on my old Windows VM but missed
commiting them as part of the gyp to gn build switch.
MozReview-Commit-ID: 7fYngpdIwxh
--HG--
extra : rebase_source : de24b50f8e19465d8c145ce96c31d4ad7cc52e57
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
A minimized window has a resolution of 1x1. Although we removed minimized windows from the list
of available windows to share, nothing prevents the user from minimizing it during a call. With
the current code, this will cause InitEncode to fail, resulting in a fatal release assert.
I tested this patch with window sharing on meet.google.com and I was able to minimize and restore
the window several times without problem. While minimized, the window appears as a black screen
to the other meeting participants. It renders normally when restored.
MozReview-Commit-ID: LE2NBiEy8nw
--HG--
extra : rebase_source : f95fd3f797e9f7262a938087ce3fb1e27f743920
It is written under lock on the controlling thread (CamerasParent) in
StartCapture/StopCapture.
MozReview-Commit-ID: E7eq1YElhwt
--HG--
extra : rebase_source : f37b666d84c6710ac0d5c56002b82c707635f49b
If we stay in the critical section, and the StartCapture() is a reconfiguring
one, we risk deadlocking with IncomingFrame which runs on the camera thread.
MozReview-Commit-ID: 5rU4urrBWxr
--HG--
extra : rebase_source : 4c6e0c1e02eb1116a1fe433681bf4ad36f47186a
Looper lifetime must be handled by external callers as otherwise internal
callers may accidentally and unknowingly quit the looper and essentially
terminate the camera thread, stopping any flow of frames and preventing future
messages.
In this case, a reconfig of the capture settings through startCapture() causes
startCaptureOnCameraThread() to restart the capture by calling into
stopCaptureOnCameraThread() (quitting the looper) and then re-calling
startCaptureOnCameraThread() (not restarting the looper as that is invalid).
The camera thread is set up by startCapture() on the external calling thread,
which will never know that a seemingly graceful camera thread operation stopped
the camera thread altogether, and so it cannot take any action.
MozReview-Commit-ID: DUTFdanTan1
--HG--
extra : rebase_source : afeb80aa8b2596a2615f57ec4af182a837323b7e
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : b13b7acdac7f1e0b6016417b83bbe97dc2417a92
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : 5a22f6d0a995303e6a4039eafc056631fbb86415
Tracing is very cheap, we should trace a bunch of stuff.
MozReview-Commit-ID: IhOyyRPXfg9
--HG--
extra : rebase_source : e6fa62f096ec269901f739bcd7f8ef6d61b79f12
extra : source : c0579ea271b9f5ff1b552fba1d4d2105b3d02eda
The cameraThread is set by startCapture(), so a failed startCapture() that
quits the Looper and runs the cameraThread to completion needs to set
cameraThread back to null for consistency.
Likewise, stopCapture() shall always quit the Looper and set cameraThread to
null.
MozReview-Commit-ID: H1ExLyTixYw
--HG--
extra : rebase_source : 472b657cd8219533a5878f5b268b6288e1fe6320
Based on output from FreeBSD i386/amd64/aarch64 and OpenBSD amd64.
MozReview-Commit-ID: 8D1u28AJTME
--HG--
extra : rebase_source : b0667e3330bbc7988d289eec27160510c60c1a3e
Original porting was done in bug 807492, so this is mostly gyp->gn translation.
cflags/libs are left unchanged as those aren't used by Gecko.
MozReview-Commit-ID: Bhw6KduoiVm
--HG--
extra : rebase_source : 485f1dfe38106b895ec481444e8a32d08f72f5e7
- If cross-toolchain is N/A use system one instead of error
- BSDs often use Linux interfaces, so don't exclude the files
- Define is_bsd as changes specific to a particular BSD are rare
- Adjust is_clang in case Gecko would use it in future
MozReview-Commit-ID: 5LlCbEKbAPO
--HG--
extra : rebase_source : 68fc72056f65c28d43d2bfb238b26b8895e76ba9
This adds a bool parameter that allows the tests to run with either the Sipcc or
Rust SDP parsers.
The tests were changed as follows: One chunk of SDP ws missing a s= line, which
is non-optional as was added. Some of the SDP had a=ice-lite as a media
attribute, but it is only supposed to be a session attribute, and so the media
attribute was removed.
MozReview-Commit-ID: K45ynsVvmnB
--HG--
extra : rebase_source : 4e2a3ea18198f8e5467706b8ef9331aa225babd2
Pause() gave the benefit of another app not being able to steal
the device until the next Run(). It would keep the light on for
some cameras however.
Stop() makes the light go out on these cameras, but put them up
for another application to steal. Basically the same as on our
other platforms.
MozReview-Commit-ID: FPRYcZ2PEpm
--HG--
extra : rebase_source : 1870eb6933b02c83c7e61ac275b648fdde9b4cec
When switching to the gn build, we accidentally began linking against the
newer webrtc.org avfoundation library rather than the locally patched,
older version. This breaks the ondevicechange event and causes other
problems.
MozReview-Commit-ID: Kz2RBK4xkjQ
--HG--
extra : rebase_source : 8ecd07177cc7de1571133d061faa57bd87a3fe4b
extra : histedit_source : 2a2044c85a28975e40996ef839c6c82926142d51
This adds a bool parameter that allows the tests to run with either the Sipcc or
Rust SDP parsers.
The tests were changed as follows: One chunk of SDP ws missing a s= line, which
is non-optional as was added. Some of the SDP had a=ice-lite as a media
attribute, but it is only supposed to be a session attribute, and so the media
attribute was removed.
MozReview-Commit-ID: K45ynsVvmnB
--HG--
extra : rebase_source : cf99d92db4c92e17dc3aa32e0862984fe69452a9
- add new component_id field to NrIceCandidatePair
- add the candidate pair component_id to RTCIceCandidatePairStats in
RecordIceStats_s
- add new column in ice stats table for component id
- sort ice stats by component id first
MozReview-Commit-ID: J89ZIYEUyRk
--HG--
extra : rebase_source : 681a5afa1303b4e377fcc14d099ce0b3d852f22c
PeerConnectionImpl defines two versions of various fallible methods: a version
taking an ErrorResult argument, and a version returning nsresult. The methods
were not marked fallible in the webidl, so the bindings called the
nsresult-returning version, but ignored the returned value. As a result,
failures got swallowed instead of being propagated out.
The changes here annotate the relevant parts of the webidl as throwing, and
convert non-fallible methods to returning void to make infallibility clearer.
MozReview-Commit-ID: JU9NzmEf8FV
Most importantly this avoids having a SourceMediaStream *with a track* but
*without any listeners*.
I'm adding asserts to ensure that all NotifyPull()s append enough data to all
live tracks.
MozReview-Commit-ID: InGj3n0f0y3
--HG--
extra : rebase_source : a9820d9943dfae12d8cc9835c594f062925ee8fa
The original logic I wrote had the condition backwards.
MozReview-Commit-ID: IFIS8vZLgd4
--HG--
extra : rebase_source : 9f9baeb2f6284c551fb63f139d6f5942569890fd
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 1cf7a41f0b8a1a95dc008f4a39536ee7e76027c4
The original logic I wrote had the condition backwards.
MozReview-Commit-ID: IFIS8vZLgd4
--HG--
extra : rebase_source : 8504e1834e39f2a244abe0a89f2235bca8cae640
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : source : 91cfd14052f510f2ba105b257a0d5dbdddb86a13
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 372440bdf73290e268d0a5318cb2c16ecfefcd2a
Historically we made a synchronous dispatch to the GMP thread on encode to avoid
copying the frame buffer. The frame buffer is now held by a refptr so we can now
make this call asynchronously.
--HG--
extra : rebase_source : 0c339d0b4721847f0f96f469fedb3320821883fd
Update the c++ side with the new WebIDL definitions, note that
many fields are now required. See P1 for more details.
MozReview-Commit-ID: FKHi86Nj7UO
--HG--
extra : rebase_source : 7491551b46a9fb0e8c8cba77861b01f90ea95644
And remove the two cases that currently set that, without actually using
it. The webrtc gtest one never relied on it, and the gfx one was added
in bug 1427668 for a single header, and the corresponding #includes were
changed in bug 1428678.
--HG--
extra : rebase_source : ebb3aed6ff8e3438d4a2f011725cf1a15986fee6
Separate setting up the ice credentials for ice restart from the actual
restart call into PeerConnectionMedia. This allows waiting until after
the call to JsepSessionImpl::CreateOffer or JsepSessionImpl::CreateAnswer
succeeds.
MozReview-Commit-ID: Hex0lNstv0H
--HG--
extra : rebase_source : 49ad2e204b7dfef6a5c359c11e38b57d8e7beade
webrtc.org only supports one-byte rtp header extensions which means
we can only support 16 character mids for now.
MozReview-Commit-ID: C7aTeB5Bi2M
--HG--
extra : rebase_source : e25518d02fb056f82d298f000e37cfe059099a38
This removes the gyp files to build webrtc. It looks like part of Bug 1371485 is
to vendor gyp elsewhere in tree at which time we can complete cleaning this up.
MozReview-Commit-ID: 8MqatafniN5
--HG--
extra : rebase_source : 2f45ef1473c2bbf2882fe867e8b535998b8dc9ef
This adds new tests that are a subset of the existing tests for configuration.
Another option would be to use parameterized tests to get coverage of all existing
tests during reconfiguration, but I don't think the additional complexity is
justified at this point.
MozReview-Commit-ID: F28KRYaVe1B
--HG--
extra : rebase_source : fdcb1316387504240424f1041d43df5d98331380
This is necessary for changes to encoding constraints and simulcast encodings to
be picked up.
MozReview-Commit-ID: JpVN0ST70Cn
--HG--
extra : rebase_source : ea61544b98e7e231527cf6f13d78862d3567b4b7
Also remove unused code.
mTrackId / mTrackIdexternal were protected/private members and only ever written.
MozReview-Commit-ID: C3wMhxSCA2H
--HG--
extra : rebase_source : 18845e480e8e2d741ef1172b212373888a9c1fe8
It can never be nullptr, strongly assert that this is the case and remove unecessary tests.
MozReview-Commit-ID: 7fi6jNnFUH8
--HG--
extra : rebase_source : 632ad1738c2984dd803c25dc44aa81c896292b64
Otherwise we will use 48kHz as default, the MSG will resample as needed.
It would be possible to allow all frequencies in the AudioConduit as the webrtc backend supports them all, however it would require more changes and likely heap allocation that we're trying to limit in this part of the code.
MozReview-Commit-ID: B3x5t1FSaQ8
--HG--
extra : rebase_source : 77f83a876ed9b5ded45419245655709aee2573df
Also remove the unmatched candidates in the candidate pair table since
they are now included in the "all raw candidates" table.
MozReview-Commit-ID: 4ZvhWfmjGJh
--HG--
extra : rebase_source : bf999db83cd49dd454434d2b157023da41b0dbcd
This is a workaround for the fact that our code is wrong.
FakeAudioDeviceModule :::TimeUntilNextProcess() returns 0, so we're busy
looping.
I'm switching that to 100, which is arbitrary, but makes the problem go away. I
want to fix that soon, because this is a terrible workaround.
FakeAudioDeviceModule is _not_ made to be used in production.
MozReview-Commit-ID: FoGs6GFsRRN
--HG--
extra : rebase_source : d62f7c2d5b98c4814c06be13aca49bd478d5b381
This allows to re-use the SharedThreadPool across calls, preventing the need to create a new thread on each call.
MozReview-Commit-ID: CbP6OTYKhHL
--HG--
extra : rebase_source : 969f2c74f00614d6265fe0e25abfb36c9648d564
There's no need for a custom class to perform this task.
MozReview-Commit-ID: JxpDQVM97fl
--HG--
extra : rebase_source : 8387efa0ed3add9e4a42daed98e97372d9cabee5
We keep the synchronous version that will be used in bug 1424653
MozReview-Commit-ID: JTGaRYm20ca
--HG--
extra : rebase_source : aa694b7ac4f03322edbdefd64cefd198c0909cec
It allows to more easily distinguish between methods from upstream webrtc.org and our code.
MozReview-Commit-ID: ILQhEAYbSmc
--HG--
extra : rebase_source : 934505afddcca9253b00c4094776c95a087058fb
Now that the graph rate match the one out of NetEQ, we can remove an unecessary conversion.
Additionally, move a member from the base case to the only one where it's used.
MozReview-Commit-ID: II5mdcl0vhK
--HG--
extra : rebase_source : 1d9edfc2803c3fadde7505b4d84293640e4311e0
Also, pass arguments are const reference.
We also rename class members as per coding style.
MozReview-Commit-ID: 9IkV8wCMpz7
--HG--
extra : rebase_source : 6dc8285342742bf19dd2d03f66dd0668fc32bbcc
It removes the need to explicitly shutdown the taskqueue and wait on the taskqueue to have run all dispatched task.
We do want to enforce that no listeners are being called once the VideoFrameConverter's owner has been destroyed as it could potentially lead to a UAF.
For now, access is okay as all operations are performed on the MSG's thread.
However, this will change in follow up patches.
The SourceMediaStream keeps a raw pointer to the MSG, and check if it's value isn't null to determine if the MSG has been shutdown or not, however SourceMediaStream::mGraph isn't thread safe as its access isn't protected by a mutex/monitor.
MozReview-Commit-ID: 1QsJAzPuE6L
--HG--
extra : rebase_source : 35f34450e62ff1f445ad6ccd06c6f6cbd3c6ed54
It's bound to be done automatically, makes it easier to modify later.
MozReview-Commit-ID: IQ5TBtS8Z3v
--HG--
extra : rebase_source : 0b1a326ada5761cfa50c33acbff9b61cf4e59c8c
The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : df4ad965c171eab5a72a8d09e0305b1e79325a03
extra : source : e92ff1339db1ca5affa56ccdbec1c8b3836bcd95
This forces us to do a copy. It's not the end of the world but could be avoided.
The number of channels received is now explicit (via
`AudioFrame::num_channels_`), instead of being guessed based on the number of
samples (considering we're always dealing with 10ms of audio, and we know the
rate).
It's still coupled a bit with audio devices, but we cheat, and use a "fake audio
device", which isn't going to touch actual OS APIs.
MozReview-Commit-ID: 1Tfajkv1HQR
--HG--
extra : rebase_source : c0c8c240621b076bb3b056689f45289212498903
extra : source : 9e92591ba6dcb18364da98756c645c91bfe81517
We used to fix the rate, arbitrarily, to 32kHz. Because the graph is almost
never running at 32kHz (more like 44.1kHz or 48kHz), and the codec would often
not be at 32kHz, this meant multiple resampling:
- Once here, in MediaPipeline, to bring to 32kHz
- Once when getting inserted in the MSG (so that the audio was brought back to
MSG rate)
- Maybe once in cubeb (depending on the platform)
This always removes the second resampling: the track is now at the correct rate,
as far as the MSG is concerned.
Additionally, if the MSG is running at 48kHz, more resampling are saved, because
it's one of the native webrtc.org rates.
MozReview-Commit-ID: DBWcwuWxUpu
--HG--
extra : rebase_source : 2b961a8bd91d952ccbe9df5a6ab7649321f282a6
extra : source : a3d9aa2649b95329d0cf686d79aa5179e9f3506d
The MSG provides the reverse stream, and feed it directly to the APM.
MozReview-Commit-ID: A6DO407CJkp
--HG--
extra : rebase_source : 65515c02928ed56d57ddd2facd586125df7f09ec
extra : histedit_source : fc61533566deca6023cb749acda96b5772661ebc
This forces us to do a copy. It's not the end of the world but could be avoided.
The number of channels received is now explicit (via
`AudioFrame::num_channels_`), instead of being guessed based on the number of
samples (considering we're always dealing with 10ms of audio, and we know the
rate).
It's still coupled a bit with audio devices, but we cheat, and use a "fake audio
device", which isn't going to touch actual OS APIs.
MozReview-Commit-ID: 1Tfajkv1HQR
--HG--
extra : rebase_source : f9ed6f1beeb3745dc17c4e6264808d1918e8906c
extra : histedit_source : 4338aea961b861462caa79afab66ebaea06e40b2
We used to fix the rate, arbitrarily, to 32kHz. Because the graph is almost
never running at 32kHz (more like 44.1kHz or 48kHz), and the codec would often
not be at 32kHz, this meant multiple resampling:
- Once here, in MediaPipeline, to bring to 32kHz
- Once when getting inserted in the MSG (so that the audio was brought back to
MSG rate)
- Maybe once in cubeb (depending on the platform)
This always removes the second resampling: the track is now at the correct rate,
as far as the MSG is concerned.
Additionally, if the MSG is running at 48kHz, more resampling are saved, because
it's one of the native webrtc.org rates.
MozReview-Commit-ID: DBWcwuWxUpu
--HG--
extra : rebase_source : 588d188f63237f1ce2cb0f2b290d54797d2d22e8
extra : histedit_source : 51733a22f6019140f7a309038a2ff524fbb564a4
Csoregi Natalia
Cosmin Sabou
Emilio Cobos Álvarez
Johannes Willbold
Jan Keromnes
Jan Beich
Jan de Mooij
arthur.iakab
Andrea Marchesini
Cameron Kaiser
Ryan VanderMeulen
Dan Minor
Christian Holler
Dorel Luca
Mike Hommey
Jim Chen
Randell Jesup
David Major
Paul Adenot
Narcis Beleuzu
Nils Ohlmeier [:drno]
Andreea Pavel
Nicholas Nethercote
Sebastian Hengst
Jan-Ivar Bruaroey
Tristan Bourvon
Andreas Pehrson
Boris Zbarsky
shindli
Byron Campen [:bwc]
Alex Chronopoulos
Nathan Froyd
Jeff Walden
Christoph Diehl
Sylvestre Ledru
Landry Breuil
Paul Ellenbogen
Andreas Pehrson
Nico Grunbaum
Masatoshi Kimura
Bogdan Tara
Robert-André Mauchin
Michael Froman
Florian Quèze
Gurzau Raul
Tom Prince
Chris Manchester
Margareta Eliza Balazs
Jean-Luc Bonnafoux
Munro Mengjue Chiang
Chris Peterson
Ciure Andrei
Jean-Yves Avenard
JW Wang
Heiher
Tiberius Oros
Jesse Schwartzentruber