Warn about Pipewire's suspension of sinks might cause troubles

[feixm1]

When using Direwolf with recent Linux distributions on amd64 and Pi with PipeWire audio subsystem with Wireplumber in its default settings, audio output sinks are being suspended after several seconds of inactivity, which results in slight delay while warming up again. This results in spitting Transmit timing error: PTT is on XXXXX mSec too long error message which is not very helpful. This pull request adds few more hints when running via ALSA subsystem.

[wb2osz]

Thanks for the enhancements.
It looks like we are are missing the alsa header file.
I'm assuming this is running in a container where we can do whatever we want.
Can we add "apt install libasound2-dev" ?

Run mkdir build
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Git: /usr/bin/git (found version "2.37.2")
-- Dire Wolf Version: 1.7.0-b679ef7
-- Build type set to: Release
CMake system: Linux
-- Target architecture: x86_64
-- Use SSE SIMD instructions
-- Looking for strlcpy
-- Looking for strlcpy - not found
-- Looking for strlcat
-- Looking for strlcat - not found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- Found Threads: TRUE
-- Checking for module 'libgps'
-- No package 'libgps' found
-- Checking for module 'hamlib'
-- No package 'hamlib' found
CMake Warning (dev) at /usr/local/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to find_package_handle_standard_args (HAMLIB)
does not match the name of the calling package (hamlib). This can lead to
problems in calling code that expects find_package result variables
(e.g., _FOUND) to follow a certain pattern.
Call Stack (most recent call first):
cmake/modules/Findhamlib.cmake:55 (find_package_handle_standard_args)
CMakeLists.txt:290 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

-- Could NOT find HAMLIB (missing: HAMLIB_LIBRARY HAMLIB_INCLUDE_DIR)
CMake Error at /usr/local/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find ALSA (missing: ALSA_LIBRARY ALSA_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/local/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/local/share/cmake-3.24/Modules/FindALSA.cmake:62 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:299 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/runner/work/direwolf/direwolf/build/CMakeFiles/CMakeOutput.log".
See also "/home/runner/work/direwolf/direwolf/build/CMakeFiles/CMakeError.log".
Error: Process completed with exit code 1.

[wb2osz]

Your new message is in the "not ARM" section so it would not be displayed on a Raspberry Pi.
Do you have any hints on what to do if this error is encountered?
Is there some ALSA configuration setting that would help?

[feixm1]

The inclusion of this new message into the not ARM section was intentional. I'm not entirely sure how often this message is actually shown on Pi and whether we are not hitting this error more often for some other reasons on Pi platform. I hit this error on both amd64 and Pi platform with PipeWire installed. Indeed, there is no other reason than this for not including it into the ARM section too.

Regarding the solution - this is not actually an ALSA issue but rather a PipeWire/Wireplumber issue which is emulating ALSA interface for DireWolf. Solution here is to disable the power saving feature of PipeWire which is suspending audio output sinks after every few secs of inactivity, which then produces this bug in DireWolf when transmitting packets after such suspension. AFAIK such a change of WirePlumber settings cannot be done via any API from within DireWolf, but needs to be done by user, as is roughly described here: https://unix.stackexchange.com/questions/676846/how-do-i-disable-audio-sink-suspend-on-idle-using-wireplumber-in-fedora-35-so-th