Includes
- Implementation in src/outputs/airplays2, type OUTPUT_TYPE_AIRPLAY
- Homekit pairing, both normal (with PIN) and transient
- New session startup sequence, incl GET /info, SETPEERS and 2 x SETUP
- No more OPTIONS and ANNOUNCE
- Use POST /feedback for keepalive instead of SET_PARAMETERS
- Sequence dispatching instead of callback chains
- Continue despite "Bad request" to SET_PARAMETER (volume)
- Opening of event connection to receiver (reverse rtsp connection)
Still to be done
- Password authentication
- Handling of events
Previously we just sent packets when ready, which especially during startup
meant a largish number of packets got sent rapidly. This seemed to cause audio
glitches. With this change the rate is adapted to follow ACKs from the device,
which is more in line with Chromium's way, though still far from the same.
Also added capability to resend packets when a nACK is received.
Also some wip attempts at sending coverart as VP8 video.
For unknown reasons some Chromecast devices disconnect causing a TLS error if
we don't OFFER a video stream. Seems actually sending video isn't required to
fix the issue.
With this commit auto reconnection per default will only be done for ATV4s and
HomePods. Reconnection is not always desirable, for instance if the device cuts
the connection because it is busy with something else, ref. issue #934.
The commit also adds an option to override auto reconnection, thus either
enabling it for other devices or disabling it for affected devices.
Include ALSA's device name in the ALSA modules 'info' logging to help
identify sound devices as seen by the system for assisting config setup
Many configs use ALSA's hw ids to refer to device but ALSA can also use
device names:
laudio: Available ALSA playback mixer(s) on hw:0 CARD=Intel (HDA Intel): 'Master' 'Headphone' 'Speaker' 'PCM' 'Mic' 'Beep'
laudio: Available ALSA playback mixer(s) on hw:1 CARD=E30 (E30): 'E30 '
From the example above can use these ALSA names interchangably:
'hw:0' and 'hw:Intel'
'hw:1' and 'hw:E30'
Before, if a user never verified the device, we would have a device->session
even though the device was not streaming and was in a failed state.
This solution should be more clean and in line with the overall principle that
we only have a session when communicating with the device.
Also includes a bit of code refactoring.
outputs_authorize() has two issues, one that the caller can't specify device
(problem if there are two devices waiting for verification), the other that it
didn't offer a standard callback, so difficult to catch failure/success.
