The change is to reduce the number of dropped frames when playing
YouTube videos. The most significant part is to set trigger threshold
to be low enough, such that as long as the audio hardware's DMA engine
moves data the callback is triggered without waiting longer. Besides
that, unify oss_wait_*fd_for_space() for both directions into a single
function. Buffer size is also not required to match the other
direction.
Sponsored by: The FreeBSD Foundation
These are minor cleanups that do not affect the behaviour of the script.
In particular, I removed most `DESTINATION` arguments from `install()`,
since they are automatically deduced based on the type of file to be
installed.
In #662 I also added doxygen_add_docs and gtest_discover_tests, but they
require CMake version 3.9 and 3.10 respectively, and I think that the
advantages they provide are not worth dropping support for older versions
Following
https://github.com/mozilla/cubeb/issues/658#issuecomment-955998734, the
speex library is now handled like a normal dependency: cubeb will link
against the system version if available, and fall back to the bundled
one if not.
I've also added a BUNDLE_SPEEX option, so that you can force the use of
the bundled library if needed (e.g. creating a standalone libcubeb on a
system where libspeex is available).
I also had to move the bundled library to a separate folder. As `src` is
always added as an include path, the headers in `src/speex` would
conflict with system headers. And it also clears the relationship
between cubeb and speex. I choose the "subprojects" name to follow the
Meson convention, since CMake does not have one. A bit OT, but if you're
curious you can see their rationale here:
https://mesonbuild.com/Subprojects.html#why-must-all-subprojects-be-inside-a-single-directory
Lastly, I added cubeb_log.cpp to the list of sources of test_resampler,
as I was getting linking errors when building with BUILD_SHARED_LIBS=true
Fixes#658
This is useful to users who can't recursively clone the repo or that
simply want to build the project from the downloadable tarball (like
Linux distributions, for example)
Users can now disable the lazy loading of libraries, and use classic
linkage instead.
Previously, cubeb would link with threads only if using some backends.
This caused linking issues when no backends were active, because cubeb
wasn't linked against pthread or similar, while the library is needed by
src/cubeb_log.cpp, as it uses std::thread.
#cleanup
The caller's requested latency in frames is based on the stream's
requested rate in `stream_params`. In the default case (when not
overriding latency for BT headsets), use this rate when converting
frames to hns.
Microsoft wave audio docs say "samples are the preferred time format in which
to represent the current position", but relying on this causes problems on
Windows XP, the only OS cubeb_winmm is used on.
While the wdmaud.sys driver internally tracks a 64-bit position and ensures no
backward movement, the WinMM API limits the position returned from
waveOutGetPosition() to a 32-bit DWORD (this applies equally to XP x64). The
higher 32 bits are chopped off, and to an API consumer the position can appear
to move backward.
In theory, even a 32-bit TIME_SAMPLES position should provide plenty of
playback time for typical use cases before this pseudo wrap-around, e.g:
(2^32 - 1)/48000 = ~24:51:18 for 48.0 kHz stereo;
(2^32 - 1)/44100 = ~27:03:12 for 44.1 kHz stereo.
In reality, wdmaud.sys doesn't provide a TIME_SAMPLES position at all, only a
32-bit TIME_BYTES position, from which wdmaud.drv derives TIME_SAMPLES:
SamplePos = (BytePos * 8) / BitsPerFrame,
where BitsPerFrame = Channels * BitsPerSample,
Per dom\media\AudioSampleFormat.h, desktop builds always use 32-bit FLOAT32
samples, so the maximum for TIME_SAMPLES should be:
(2^29 - 1)/48000 = ~03:06:25;
(2^29 - 1)/44100 = ~03:22:54.
This might still be OK for typical browser usage, but there's also a bug in the
formula above: BytePos * 8 (BytePos << 3) is done on a 32-bit BytePos, without
first casting it to 64 bits, so the highest 3 bits, if set, would get shifted
out, and the maximum possible TIME_SAMPLES drops unacceptably low:
(2^26 - 1)/48000 = ~00:23:18;
(2^26 - 1)/44100 = ~00:25:22.
To work around these limitations, we just get the position in TIME_BYTES,
recover the 64-bit value, and do our own conversion to samples.
Format all the code under `include` and `src` except those files under
`src/speex` with style setting in `.clang-format` file by the following
script:
```sh
FILE_LIST="$(find "include" "src" -not -path "src/speex/*" | grep -E ".*(\.cpp|\.c|\.h|\.hpp|\.hh)$")"
echo "Files found to format:\n---\n$FILE_LIST\n---"
clang-format --verbose -i $FILE_LIST
```
There is a bug in the OSS cubeb code which use the previous number of
frames as input for the next data-exchange, when full-duplex is
activated. This causes noticable jitter, because the wrong number of
audio frames is exchanged.
The solution is to check both input and output audio DSP buffers and
select the minimum number of audio frames which can be transferred when
full duplex is activated.
On some device (namely, a Samsung Galaxy A30 running Android 10, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1679932), the state is
"STARTED" for quite some time, so we don't go into the `if` statement.
It's best to fallback.
We then need to ensure the monotonicity of this clock (since now we use
two distinct ways of reporting the time, it can end up being
non-monotonic for some calls), using the same technique we use on other
backends.
Reduce the code complexity of non-blocking IO all together. Besides, we
should let recording direction driving the playback direction if we are
working with duplex stream.
- Fix misuse of SNDCTL_DSP_GETOSPACE ioctl on record.fd as well
- Add more comments regarding buffer initialization
- Address comments about which direction driving another direction
Matthew Gregan
Ka Ho Ng
Andrea Pappacoda
pent0
mixit
Paul Adenot
Chun-Min Chang
Ryan Hileman
Alexandre Ratchov
Tomas Maly
Hans Petter Selasky
Nicola Orlando
Albert Liu