pulse/alsa/oss do not reliably work with ALAW/ULAW codecs with all
hardware available.
Since these formats are poor quality anyway, deactivate them for
audin channel.
(cherry picked from commit c3e8720c87)
tsmf_ifman_exchange_capability_request did not check if the input
data stream actually contained the amount of bytes requested to
copy.
(cherry picked from commit 4182bfbf38)
tsmf_ffmpeg_init_stream did not abort if the video format ExtraDataSize
was not sufficiently large to satisfy expectations.
(cherry picked from commit 5beef2c5e6)
* Moved clipboard utils to core library, fixes#6760
(cherry picked from commit 4fb686d40f)
* Fixed compilation warnings in cliprdr_utils
(cherry picked from commit 8b7a086411)
* Fixed backport API mismatch
* Added C++ guards to header
(cherry picked from commit 7626a2ce6a)
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.
