Update head.js so that calls to the gUM helper will check the loopback and fake
device prefs and update the frequency output by test devices accordingly. This
should hopefully avoid issues where tests could change prefs, and the output
tone would no longer be correct for the new configuration.
No longer have audioDevice and videoDevice as globals, this way tests
explicitly fetch direct from prefs.
MozReview-Commit-ID: 9jhVScaBfTX
--HG--
extra : rebase_source : 64b17e44ef166983361f94cf7d287faed3c2cdc5
Update the DeviceEnumerationType enum to scoped style enum for safety and
consistency. Add extra logging to aid in debugging test issues.
MozReview-Commit-ID: cm5bdlIcEG
--HG--
extra : rebase_source : bfcae3d49f809edfd0ed6ab3e516b8be0c0d517e
Update head.js so that logic for fake audio and fake video is more granular.
Now code handles fake audio and fake video separately, and will set the fake
pref is either is needed. This allows for a single loopback device to be set
and fake used for the other. Previously both devices needed to be loopback or
fakes would be used.
MozReview-Commit-ID: K4blmPrSVeh
--HG--
extra : rebase_source : 369ea7f788d29a02db68e517d324977f251c9a98
With changes giving loopback devices higher precedence in testing, various tests
in dom/media/tests/mochitest have been updated to accommodate this. Many tests
just worked, but some require tweaks, or to explicitly request fake devices.
Also update webaudio's test_mediaStreamAudioSourceNodeGC test to explicitly use
fake devices. This test does not have the loopback tone exposed to it in JS, so
is unabel to adjust the loopback tone to suit its needs.
Various tests are updated to set fake device prefs instead of requesting via
gUM to move away from non-standard behaviour per bug 1436424.
MozReview-Commit-ID: 5GAVZFzF2hq
--HG--
extra : rebase_source : 27f39e3573eda321025ce0739e1d5f4101fc5d12
This changeset adds a gUM_support.js to dom/media/test/. This file provides
functions to setup prefs for loopback or fake device selection before gUM calls
are made. This is useful for configuring tests and providing an explicit point
of reference for settings, rather than the implicit ones provided by the
harness.
Updates tests so that the new helper functions are called before gUM. This
will result in loopback prefs being set if loopback device names are detected,
if not then fake devices will be used. This also removes the use of the fake
constraint in gUM calls.
Update touched tests to use some more modern JS. No behavioural changes were
made (except in minor cases, but functionality should be the same). These
changes are largely as follows:
- var -> let
- async is used in places where I felt it improved readability
- semicolons added to various event handler assignments
MozReview-Commit-ID: 1HuE8thBA6w
--HG--
extra : rebase_source : b866056b2821436cf34ea683421c200b4bb4e55f
Change the media manager so that if fake and loopback devices are requested,
loopback is preferred. With this change loopback and fake devices can also be
mixed. Since the fake flag is coarse, and does not specify fake audio or video,
we would previously just make everything fake. As loopback sets flags for video
and audio separately, we can now request a single loopback device, while also
setting the fake flag to get a mix. E.g. if we request a loopback audio device,
and set the fake flag, we should get loopback audio and fake video.
This change also attempts to somewhat consolidate where these settings take
place. Previously, EnumerateRawDevices did much of the loopback setup. However,
other steps around fingerprint resistance or fake devices were done in earlier
functions (EnumerateDevices and GetUserMedia). This changeset moves the loopback
setup so that it's more consolidated with the other setup code in these
functions.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 374a6fd0842a430e27c695bcf956e2e072a77fc3
Prior to this patch various bools are used to track if we requst fake or
loopback devices during enumeration. However, since the normal, fake, and
loopback cases are mutually exclusive, a enum can be used. This provides allows
for having descriptive enum values in code and makes clear that the settings are
mutually exclusive.
MozReview-Commit-ID: FF0bR0Nyws9
--HG--
extra : rebase_source : 498513bdc6673fa299080097364a6d0dff00a073
Stop us potentially keeping a stale device list when updating if we can't get a
cubeb context.
MozReview-Commit-ID: H6GdeNXObWV
--HG--
extra : rebase_source : 48fce949627fa17402336db824374847e1b439e6
Add logging to aid in debugging of our EME ADTS conversion path.
MozReview-Commit-ID: A7Wv8n31V8V
--HG--
extra : rebase_source : 13f20179aa29180047a37a127029d0e28a1c4f80
Update EMEDecoderModule to use 2 as profile number when the given profile is
less than 1 or greater than 4. The CDM doesn't appear to care what values are
given, but 2 was chosen as a safe fallback per discussion on the bug. This
addresses the use case where 0 values are stored in mProfile due to the use of
extended profiles (which are then stored in the mExtendedProfile field).
MozReview-Commit-ID: 5XgabNDsgdf
--HG--
extra : rebase_source : dd66a872aaac2acf4af55f06d3c24f53debe4e63
This prevent potential division by zero should the cast on the argument cause an overflow.
We still limit the mul and div arguments to INT64_MAX.
MozReview-Commit-ID: gHkv6m4zq0
--HG--
extra : rebase_source : 1c27f9a2ecc4c8bf6a763dedf2859e64bf79ea85
Disable time jittering when comparing different AudioContexts because they might look
different.
MozReview-Commit-ID: A3neLqokQ5c
--HG--
extra : rebase_source : b275942db06d3bb8e80bdb6ed5f94299636d1a8f
Apple layout standard has a 1:1 equivalence with the WAVE standard. As such, any streams under 18 channels, properly defining a channel layout, should play on all platform.
Otherwise, as Opus and Vorbis, the result will be platform dependent.
MozReview-Commit-ID: ID6b9u2UNQr
Under 8 channels, the audio will be reordered so it can be playable on any platforms.
Over 8 channels, the channels will be as output by the decoder. Playing of such stream will be platform dependent as neither Opus nor Vorbis define a channel layout with more than 8 channels.
With WebAudio however, the result will be platform independent (as long as you don't attempt to play it)
MozReview-Commit-ID: 93ATiKm9y20
This will allow to create an AudioConfig with an unknown or unsupported channel layout, defaulting instead to the number of channels.
MozReview-Commit-ID: IonLuo9q2a5
If a channel layout is unsupported, the AudioConverter will instead just use the channel count information to leave the data as-is, only trimming extra channels, or inserting silence if needed.
MozReview-Commit-ID: CXOjcSRsRwI
Instead we place it at 32.
Future changes will change the meaning of this limit to when we can deal with channel layout. If outside that limit the audio will be played on a best attempt basis.
MozReview-Commit-ID: EavmmcxjLI0
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
That ChannelLayout uses an AutoTArray internally makes XPCOM report them as leaking when declared as static.
They weren't use outside of ChannelLayout anyway so they can be removed.
MozReview-Commit-ID: KVqdjzvL8pr
It makes no sense to have a case for those as the data structure used (a bitmask) do not allow to represent this channel layout (a channel can only be present once). As such it was a non-functional layout
MozReview-Commit-ID: FjA0fojFcJp
