| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Possible fix for test_loopback assertion failure.
|
|
called.
|
|
Some systems offer OSS v4 but do not have BSD-only functions like
strlcpy, used in cubeb_oss.c. An example is Debian GNU/kFreeBSD, that
uses a FreeBSD kernel with GNU userspace utilities, like glibc.
With this patch cubeb will be able to build on these systems thanks to
the help of libbsd, that privides most libc functions that you would
expect on BSD.
|
|
Also when the latency is specified to be very big.
This might be a bug in some upper layer, although I see
other cubeb audio drivers doing the same.
This "fixes" audio sync with youtube videos.
|
|
|
|
|
|
flow/role instead of requerying for every wasapi_create_device.
Locally (on a machine with ~120 devices), this reduces a single
enumerate_devices call from ~1100ms to ~250ms.
|
|
When computing the maximum buffer size the "fragstotal" field should be
used instead of "fragments" field. For recording the "fragments" field
usually returns zero, so then no recorded audio may be received.
While at it remove the not used "nfr" and "nfrags" fields from the
oss_stream structure and use "bufframes" instead.
|
|
Original downstream patch by Tom Ritter <[email protected]>.
|
|
Fixes issue #677.
|
|
The hardware buffer is typically bigger than the software buffer.
Make sure to properly limit the available buffer size values
obtained from the DSP device.
While at it ensure to retry-polling in case either recording or
playback cannot move any data.
|
|
|
|
|
|
Fixes #676.
|
|
This is required since the install() cleanup in
e690fc21bbfbedaf61a704fbc86c4bbdc304b5ed.
|
|
There were some type mismatch and signed/unsigned comparison warnings
in the initialization path.
Sponsored by: The FreeBSD Foundation
|
|
|
|
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
|
|
|
|
|
|
|
|
This speeds up compilation times and makes downstream packaging easier.
|
|
|
|
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.
|
|
|
|
Turns out it was testing the preroll, and with the preroll gone from the
pulse-rust backend in https://github.com/mozilla/cubeb-pulse-rs/pull/69,
this fails on (at least) docker-on-AWS hosts.
|
|
|
|
|
|
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
```
|
|
See BMO #1722073.
|
|
Add a multiple input devices test
Add a test to check if we can open multiple input devices at the same
time. This is a simple check for BMO 1238038.
|
|
streams. Closes #643.
|
|
|
|
|
|
|
|
|
|
|
|
(fixes #647)
|
|
cf https://bugzilla.mozilla.org/show_bug.cgi?id=1633769
|
|
IAudioStreamVolume.
|
|
|
|
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.
|
