Mike Brady
b405c0b896
New Features:
Multi-Channel and High-Resolution Audio Support
48,000 frames per second ("48k") operation.
48k lossless stereo support.
5.1 and 7.1 surround sound support.
Multi-channel and multi-rate operation on ALSA, PipeWire, PulseAudio, FreeBSD, stdout and Unix pipe output backends.
Automatic Audio Format Selection
Flexible and controllable output format selection.
Automatic rate, sample format, and channel count selection.
Full FFmpeg Integration
Support for transcoding.
Advanced resampling capabilities.
New audio format support.
Enhanced Resampling
New vernier resampling and interpolation method optimized for low-power CPUs.
Better performance on resource-constrained devices.
Convolution and Loudness Enhancements:
Convolution system is now multithreaded and works on stereo and multichannel audio at 48k and 44.1k.
Multiple impulse response (IR) files can now be provided via convolution_ir_files setting.
New convolution_thread_pool_size setting for multithreaded processing (defaults to 1).
Loudness processing now works with stereo and multichannel audio at 48k and 44.1k.
Updated to the most recent HiFi-LoFi FFT convolver.
MQTT Enhancements:
Added new publish_retain boolean option. When enabled, published MQTT messages have the retain flag set, so the MQTT broker stores the last message per topic and new subscribers receive the most recent value immediately. Thanks to lululombard for PR #2142.
D-Bus Enhancements:
Added new dbus_default_message_bus command-line argument (can be system or session) to set the default message bus for both D-Bus native service and MPRIS service.
Performance Improvements:
Enhanced compatibility with AirPlay 2 AutoMix and Smart Tracklists resulting in less unexplained track skipping.
Better operation on low-power devices down to Raspberry Pi B.
Improved efficiency on embedded systems.
Enhanced timestamp handling for better synchronization.
Improved sync error calculation.
Rebuilt buffered audio processor for cleaner handling of immediate and deferred flush requests.
Docker Enhancements:
Reduced Docker image sizes with slimmed-down FFmpeg library.
Removed dhclient from Docker images for smaller footprint.
Bug Fixes:
Fixed MQTT warning on service startup: "Could not establish a mqtt connection". The startup script now correctly states that the mosquitto service is required. Thanks to Hugo Villeneuve for PR #2137.
Fixed compatibility with mbedtls library version 3.4+ (present on recent Linux versions). Thanks to Christian Beier for finding and fixing the bug.
Fixed PulseAudio backend so that PA_ERR_NODATA returns "No latency data yet". Thanks to Vladimir Shakov for the report and fix.
Ensured old flush requests are deleted when a new play session starts. Thanks to saujanyashah for the report.
Fixed format warnings on 64-bit and 32-bit systems
Removed compilation warnings on 32-bit builds
Improved argument checking for debug(), inform(), warn() and die() functions
Fixed "daemon" typos throughout codebase. Thanks to Chris Boot for PR #1981.
Added warning if a convolution impulse response file cannot be read due to bad path or permissions
Build System Improvements:
Unified service file with variable substitution for Avahi support, making it easier to add future service dependencies. Thanks to Hugo Villeneuve.
Network interface selection now only considers interfaces that are up, running and not loopback interfaces. Thanks to Carl Johnson for the suggestion.
Configuration File Changes and Deprecations
New settings: convolution_ir_files (replaces convolution_ir_file), convolution_enabled (replaces convolution), convolution_max_length_in_seconds (replaces convolution_max_length), loudness_enabled (replaces loudness).
New convolution_thread_pool_size setting (defaults to 1).
Deprecated settings: convolution_ir_file, convolution, convolution_max_length, loudness.
Corresponding D-Bus methods and properties have been updated.
Deprecation Notice:
The Jack Audio and soundio backends are deprecated and will be removed in a future release. Consider using the updated PipeWire backend instead.
Documentation Updates
Updated BUILD.md with latest build instructions.
Updated AIRPLAY2.md with feature information.
Enhanced convolution and loudness documentation.
Maintenance:
Fixed FFmpeg deprecation warnings.
Bumped actions/checkout from 6.0.1 to 6.0.2.
Bumped docker/login-action from 3.6.0 to 3.7.0.
Bumped docker/build-push-action from 6.13.0 to 6.15.0.
Bumped docker/setup-qemu-action from 3.4.0 to 3.6.0.
Bumped docker/setup-buildx-action from 3.9.0 to 3.10.0.
pair_ap
C client implementation of pairing for:
- Apple TV device verification, which became mandatory with tvOS 10.2 (this is called fruit mode in pair_ap)
- Homekit pairing (also for AirPlay 2)
Credit goes to @funtax and @ViktoriiaKh for doing some of the heavy lifting.
Requirements
- libsodium
- libgcrypt or libopenssl
- libplist (only for Apple TV device verification)
To build the example client and server you also need libevent2. If the dependencies are met you can build simply by running 'make'.
Homekit pairing
Since I haven't been able to find much information on the internet on how Homekit pairing is designed, here is a write-up of my current understanding. If you know better, please help improve this.
With Homekit pairing, there may be a controller (e.g. the Home app), and a number of devices/accessories (e.g. speakers). The controller acts as a client and can make requests for pairing. After it is paired it can also add other "third-party" pairings to the device, it can remove pairings and it can ask for a list of pairings.
Other parties, e.g. the Music app or just iOS as an Airplay sender, can also pair with devices/accesssories in a similar manner, but they are not full- fledged Homekit controllers and thus don't make requests for adding, removing or listing pairings.
The controller uses /pair-add to make sure that all devices on a network get
the ID and public key of all the other devices, so that the user only needs to
pair a device once.
Normal pairing with one-time code
For a normal first-time pairing, the client needs a one-time code (the device
announces via mDNS whether a code is required). The client calls
/pair-pin-start and the device displays the code. There is also QR-based
pairing, which is (probably?) an encoded code.
After obtaining the code, the client initiates a three step /pair-setup
sequence, which results in both peers registering each other's ID and public
key. Henceforth, a pairing is verified with the two step /pair-verify, where
the parties check eachothers identify. Saving the peer's ID + public key isn't
strictly necessary if client or server doesn't care about verifying the peer,
i.e. that /pair-setup has actually been completed.
The result of /pair-verify is a shared secret that is used for symmetric
encryption of the following communication between the parties.
Transient pairing
Some devices don't require a code from the user for pairing (e.g. an Airport
Express 2). If so, the client just needs to go through a two-step /pair-setup
sequence which results in a shared secret, which is then used for encrypted
communication. A fixed code of 3939 is used.
The controller can still use /pair-add etc. towards such devices.
"fruit" pairing
Like normal Homekit pairing, this consists of first requesting a code with
/pair-pin-start, then a three-step /pair-setup and finally a two-step
/pair-verify. After that the communication is encrypted with the resulting
shared secret.