Most dynamic channels share the same copied and pasted code for the XXX_CHANNEL_CALLBACK
and XXX_LISTENER_CALLBACK types. This patch introduce GENERIC_CHANNEL_CALLBACK and
GENERIC_LISTENER_CALLBACK that fits for most channels and discard custom type definitions.
commit ec699f6c75 moved the array
allocation into display_convert_rdp_monitor_to_monitor_def without
updating its only call site.
This leads to display_convert_rdp_monitor_to_monitor_def failing
because the array already exists.
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
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.
* core: correctly handle console mode server-side
In server-side we were not interpreting redirected session flag to compute a
console mode flag. In the proxy that was leading client connecting with /admin to front
to not connect with /admin on the back server.
* nla: fix the printinng of the package name
