Wrap read() with the CHECK() used elsewhre in the test program, in order
to render out the compiler warning represented by this transcript:
➜ pipewire (af38edea) ✔ make
ninja -C /home/jarkko/Projects/pipewire/build
ninja: Entering directory `/home/jarkko/Projects/pipewire/build'
[6/397] Compiling C object spa/plugins/alsa/test-timer.p/test-timer.c.o
../spa/plugins/alsa/test-timer.c: In function ‘main’:
../spa/plugins/alsa/test-timer.c:195:3: warning: ignoring return value of ‘read’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
195 | read(state.timerfd, &expirations, sizeof(expirations));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
Use a different way to generate the upper bits of the ASYNC mask
instead of undefined shift as warned by sanitizer
Add some unit test for this
See #497
Instead of using a hardcoded value for the minimum delay between writes,
select it according to the mtu/packet size that is currently used.
This is necessary for correct playback with lower mtu values.
Kernel should provide the correct mtu/packet size to use for SCO socket
I/O, but it does not currently appear to (as of linux 5.9), see
https://lore.kernel.org/linux-bluetooth/20201210003528.3pmaxvubiwegxmhl@pali/T/
When using mSBC, instead of using the (incorrect) kernel-provided value,
hardcode mtu to 24, corresponding to ALT1 mode. BT-UART adapters should
not require specific mtu, and it appears most BT-USB adapters only
support ALT1, see
https://lore.kernel.org/linux-bluetooth/20201210012003.133000-1-tpiepho@gmail.com/
This code needs to be revised when the issue is sorted out on the kernel
side.
Add setting bluez5.msbc-force-mtu for easier debugging in special cases.
Leave read_mtu as the detected value --- it does not seem to affect
whether BT-USB can record, but Raspberry Pi BT-UART fails to record if a
different value is used.
Currently alsa_read and alsa_write assumes that all the frames committed
using snd_pcm_mmap_commit are read or written, which is probably true.
However, as it could be some corner cases add a warning to notice this
fact.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
The codepath `pa_alsa_ucm_add_ports` -> `probe_volumes` ->
`pa_alsa_path_probe` was never called leading to no HW volume being set
up when loading a card through UCM. PulseAudio calls this from
`card_set_profile` -> `pa_alsa_{sink,source}_new`.
