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
The rdpContext gets an event which will
get set if an error occoured in a channel.
If a thread or a void callback has to report an
error it will get signaled by this system.
With BOOL as return type it is not possible to differentiate between
success and "no data can be read" (when a channel read would block).
rdpsnd_server_handle_messages returns now int with the following
possible values:
-1 if no data could be read
0 error (like connection close) (formerly FALSE)
1 succsess (also if further bytes need to be read) (formerly TRUE)
Not using -1 for error cases was chosen to be compatible with the BOOL
return values used before.
MS-RDPEA 2.2.2.3 states (Appendix A <6>) that quality mode PDU
should be ignored if the client version is < 6. For these clients the sound
channel got never activated since activated was only called after
reception of the quality mode PDU.
For clients < version 6 activated is now called after
CLIENT_AUDIO_VERSION_AND_FORMATS was received.
