`:` is a reserved character on Windows filesystems.
As far as I can tell from looking through both PulseAudio and PipeWire
commit history the files under `alsa/mixer/samples` are not used or
installed by anything.
See #2474.
This provides access to GNU C library-style endian and byteswap functions.
Windows doesn't provide pre-processor defines for endianness, but
all current Windows architectures (X32, X64, ARM) are little-endian.
The `LoopUtils` interface can be used on platforms that don't
support the Linux-specific `timerfd` interface.
Added `local-videotestsrc` to validate the plugin still functions.
Restructured the SDL event loop as the window would not update
under WSL2, resulting in a black window being shown. All rendering
in SDL2 must happen on the same thread that originally created the
renderer.
To prevent the SDL event loop from being starved, we make sure to
poll it at least every 100 ms.
I believe the intent here is that if a `interval` is provided
but `value` is unset, then `value` should default to `period`
so the timer first fires after one `interval`.
Since `interval` is always a relative duration, `value` should
be interpreted as a relative duration, not an absolute one.
This is somewhat similar to the S32->F32 conversion improvements,
but here things a bit more tricky...
The main consideration is that the limits to which we clamp
must be valid 32-bit signed integers, but not all such integers
are exactly losslessly representable in `float32_t`.
For example it we'd clamp to `2147483647`,
that is actually a `2147483648.0f`,
and `2147483648` is not a valid 32-bit signed integer,
so the post-clamp conversion would basically be UB.
We don't have this problem for negative bound, though.
But as we know, any 25-bit signed integer is losslessly
round-trippable through float32_t, and since multiplying by 2
only changes the float's exponent, we can clamp to `2147483520`!
The algorithm of selection of the pre-clamping scale is unaffected.
This additionally avoids right-shift, and thus is even faster.
As `test_lossless_s32_lossless_subset` shows,
if the integer is in the form of s25+shift,
the maximal absolute error is finally zero.
Without going through `float`->`double`->`int`,
i'm not sure if the `float`->`int` conversion
can be improved further.
There's really no point in doing that s25_32 intermediate step,
to be honest i don't have a clue why the original implementation
did that \_(ツ)_/¯.
Both `S25_SCALE` and `S32_SCALE` are powers of two,
and thus are both exactly representable as floats,
and reprocial of power-of-two is also exactly representable,
so it's not like that rescaling results in precision loss.
This additionally avoids right-shift, and thus is even faster.
As `test_lossless_s32_lossless_subset` shows,
if the integer is in the form of s25+shift,
the maximal absolute error became even lower,
but not zero, because F32->S32 still goes through S25 intermediate.
I think we could theoretically do better,
but then the clamping becomes pretty finicky,
so i don't feel like touching that here.
At the very least, we should go through s25_32 intermediate
instead of s24_32, to avoid needlessly loosing 1 LSB precision bit.
That being said, i suspect it's still not doing the right thing.
Why are we silently dropping those 7 LSB bits?
Is that really the way to do it?
At the very least, we should go through s25_32 intermediate
instead of s24_32, to avoid needlessly loosing 1 LSB precision bit.
FIXME: the noise codepath is not covered with tests.
The largest integer that 32-bit floating point can exactly represent
is actually `(2^24)-1`, not`(2^23)-1` like the code assumes.
This means, whenever we use s24 as an intermediate step
to go between f32 and s32, we lose a bit of precision.
s25_32 is really a i32 with highest byte always being a sign byte.
Printing was done by adding
```
for(int e = 0; e != 13; ++e)
fprintf(stderr, "%16.32e,", ((float*)m1)[e]);
```
to `compare_mem`. I don't like how these tests work.
https://godbolt.org/z/abe94sedT
Can be used to group ports together. Mostly because they are all from
the same stream and split into multiple ports by audioconvert/adapter.
Also useful for the alsa sequence to group client ports together.
Also interesting when pw-filter would be able to handle streams in the
future to find out what ports belong to what streams.
This fixes the endianness of the parsed broadcast code. It also
fixes pontetial out-of-bouns write by using a bigger, temporary
bcode string, then, after checking it's length, copying it's content
to big_entry->broadcast_code.
It's not used anymore because it does work so well.
The problem is that while it transparently proxies param enums on
ports to peers, it fails to emit events when those peer
params change in a way that would make the enum result change as well.
This makes it quite hard to use this correctly.
6e581deb91 added an `spa_autoptr(DbusMessage) m`
for the new message sent out when a signal is received from modemmanager.
However this ended up shadowing the original `m` function arg,
so the code that wanted to interrogate the original arg with
`dbus_get_message_path` etc ended up interrogating this `NULL` value instead.
This triggered a NULL-check in `dbus_get_message_path` and caused
the process to abort.
Original downstream report: https://gitlab.com/postmarketOS/pmaports/-/issues/2886
Currently, the user sets the Broadcast Code via an array of integers
in the config file. However, the Bluetooth Core Specification indicates
that it should be set via a 16 byte string. This commit replaces the old
implementation with the one required by the spec.
Tested the commit with the example provided in the Core Spec:
Broadcast Code: Børne House
Result from btsnoop log:
< HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31
...
Broadcast Code[16]: 000000006573756f4820656e72b8c342
The result matches the example given in the spec.
Add "encryption" parameter to bluez5.bcast_source.config entry in
the configuration file. This allows the user to control the use of
Broadcast encryption.
Advertise support for the videotransform metadata.
Make a new meta.videotransform.transform property to configure the
desired video transformation in the metadata.
This makes it possible for a session manager or other rules to set
a custom transformation on the source.
See #4034
When bound_ctl info cannot be read this array elem info
is set to NULL in 'fetch_bind_ctl'. So when we iterate
the bound_ctl array we always have to check this.
In ACP mode, we might be accessing front:0 as the PCM, and using that
string to generate the ctl device name does not make sense. In
PulseAudio, we used the card index to generate a hw:X string, and we
replicate that here.
Fixes: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4028
Kernel-provided MTU does not work for USB controllers and the correct
packet size to send can be known currently only from RX. So we are
waiting for RX to get it.
The known problem is USB-specific, we shouldn't need the workaround for
other transport types.
Don't wait for POLLIN for non-USB controllers on connect, but ready
things on POLLOUT as usual.
For non-USB controllers, pick some sensible packet sizes to use
initially, before we switch to same size as for RX.
