This moves the application of volume and averaging of channels to the main
thread, performed when required. It avoids a potential allocation on the
graph thread. If doing a full analysis for frequency data, the extra work on
the main thread should be negligible. I assume that repeatedly fetching the
same time domain data with getFloatFrequencyData() is not something we need to
optimize for. If, in rare circumstances, the extra main thread work turns out
to be significant, then the main thread work in getters is self-regulating,
but too much load on the graph thread leads to catastrophic failure in the
audio.
This also fixes some bugs:
Input and output streams for other consumers are not corrupted by in-place
scaling of data intended to be read-only.
When there are additional channels and fftSize < WEBAUDIO_BLOCK_SIZE, the
channels are not written past the current length of a buffer, so there is no
longer a dependency on nsTArray's behavior of never not reducing allocation
size on length changes.
The most recent fftSize samples are now used even when fftSize <
WEBAUDIO_BLOCK_SIZE, instead of the first fftSize samples in the most recent
block.
Enough time domain data is recorded so that getters will work immediately
following a change in fftSize.
--HG--
extra : rebase_source : bbd8a3e705d73781bb838a47261bf7d60cd1a9a7
Some mozconfigs don't include mozconfig.linux*, and don't get gtk-related
definitions, so move them in a separate mozconfig. To avoid having two
files, one for 32-bit builds and one for 64-bit builds, rely on the
includer to set PKG_CONFIG_LIBDIR appropriately.
At the same time, move all the --enable-default-toolkit=cairo-gtk2 in that
new file in the case the gtk3 package wasn't pulled from tooltool.
The current situation looks like this: Firefox launches the plugin-container
with two environment variables set:
LD_LIBRARY_PATH=$FIREFOX_DIR:$LD_LIBRARY_PATH
LD_PRELOAD=$FIREFOX_DIR/libmozgtk2.so:$LD_PRELOAD
libxul.so has a dependency on libmozgtk.so (without "2"), but libmozgtk2.so
has a SONAME of libmozgtk.so, so ld.so recognizes libmozgtk2.so as a
dependency of libxul.so, and uses it instead of the actual libmozgtk.so,
making the plugin-container use Gtk+2 instead of Gtk+3 to load Gtk+2 plugins.
Now, ASan sets things up in shared libraries such that they needs a symbol
from the executable binary. So in the case of plugin-container, the
plugin-container executable itself contains some ASan symbols such as
__asan_init_v3. libmozgtk2.so, OTOH, contains an undefined weak reference to
that symbol, like all other Firefox shared libraries.
Since libmozgtk2.so is LD_PRELOADed, it is loaded _before_ the
plugin-container executable, and __asan_init_v3 can't be resolved.
Disabling ASan for libmozgtk2.so would be a possibility, but the build system
doesn't really know how to do that, and filtering out -fsanitize=address
can be fragile.
The alternative possibility, implemented here, is to change the library
loading strategy, renaming libmozgtk2.so to gtk2/libmozgtk.so, and setting
the following environment variable when Firefox launches the plugin-container:
LD_LIBRARY_PATH=$FIREFOX_DIR/gtk2:$FIREFOX_DIR:$LD_LIBRARY_PATH
There are a variety of ways that the parent and child process ensure that
the child process exits quickly in opt builds, but for AddressSanitizer
builds we want to let the child process to run to completion, so that we
can get a LeakSanitizer report.
This requires adding some addition LSan suppressions, because running
LSan in child processes detects some new leaks.
