The OSMINORTYPE_NATIVE_WAYLAND value does not officially exist in
[MS-RDPBCGR].
Its value also is the one for Windows RT.
Fix this situation, by introducing the os minor type
OSMINORTYPE_WINDOWS_RT with its correct value and by choosing a
different value for OSMINORTYPE_NATIVE_WAYLAND, as that value does not
exist officially.
With LibreSSL 2.7.0 (or newer versions) some more structs have made
opaque, which requires a few changes:
- BIO_meth_new() and related functions are now defined by LibreSSL, the
versions from opensslcompat.{h,c} does not need to be used anymore.
- HMAC_CTX is now opaque, HMAC_CTX_new(), EVP_MD_CTX_new, and related
functions should be used instead in winpr's hash.c.
This allows server implementations to add handling for situations,
where the client side does not support them.
Particularly useful for the audio output channels (static channel as
fallback, when dynamic channel is not supported).
The current server sided channel handling of RDPSND/AUDIO_PLAYBACK_DVC
is currently very constrained.
So, solve this. This means:
- Add the missing Training/Training Confirm PDUs
- Stop overriding the average bytes per second values, when submitting
the audio formats, as this currently makes the usage of codecs
impossible
- Add a way to send the server formats manually again, to be able to
restart the protocol after a Close PDU was sent
- Add a way to send already encoded audio data to let server
implementations to take care of the encoding process and to set
custom audio timestamps for the Video Optimized Remoting channel
- Add public attributes to let server implementations know the initial
volume and pitch values
- Add public attribute to let server implementations know the quality
mode setting
(cherry picked from commit 26488911be9ae8e00f77f075e03ddbe4dc70a402)
The [MS-RDPEGFX] spec is not really sure which value to use, so we
just announce both, the one from the spec and the one from errata.
(cherry picked from commit 8df9170b5d)
Currently, all FreeRDP-based clients don't send any WaveConfirm PDUs
for received samples, when using a dynamic channel for audio output
redirection.
[MS-RDPEA] 2.2.3.8 Wave Confirm PDU mentions, that a WaveConfirm PDU
MUST be sent, when a WaveInfo PDU + Wave PDU, or Wave2 PDU is received
and when the audio data sample is emitted to completion by the client.
The first WaveConfirm PDU is used by the server to determine the
network latency and the second WaveConfirm PDU is used by the server to
determine the render latency.
So, fix the current behaviour, where FreeRDP currently does not send
any WaveConfirm PDU, when using the dynamic channel, or only sends one
WaveConfirm PDU for the sample.
For the first WaveConfirm PDU, use the same timestamp, that was
included in the first WaveInfo/Wave2 PDU.
For the second WaveConfirm PDU, add the render latency on top of the
arrival timestamp.
