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.
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.
_align_XXX functions aren't widely available depending on the C runtime. That causes
problems with mingw where we can easily have some runtime mixes (which lead to mysterious
segfaults most of the time). This patch introduce winpr_aligned_XXX functions that will
either use the function available, or use an emulation layer.
