none
[MS-RDPEA] Is there anyway to ask next Wave PDU RRS feed

  • Question

  • Hi all,

    When I played video with RemoteFX enabled client, the audio is usually choppy in lower performance client or low bandwidth connection.

     

    To look into the issue, I found that each interrupt was followed an underrun exception.  

    It looks like RDP server did not send next Wave PDU in time before hardware consumed all of wave data in buffer.

     

    My question is, Is there any way to ask next Wave PDU from RDP server in RDP client?

    To return an large delay time in Wave Confirm PDU could be helpful?

    Wednesday, June 8, 2011 7:05 AM

Answers

  • CSaint,

     

    I didn’t see a response to this issue via either “dochelp (at) microsoft (dot) com” or this forum thread.  Was it resolved?  I’m going to close this on our end.  But, if this still requires attention, please contact us.

     

    Bryan


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Tuesday, July 19, 2011 7:22 PM
    Moderator

All replies

  • Hi CSaint,

     

    Thank you for your question.  An engineer from the Protocols team will reply soon.

     


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Wednesday, June 8, 2011 4:19 PM
    Moderator
  • hi all,

    I found that intervals between each Wave PDU is unpredictable. 

    Log 1.
    [get Wave PDU]  duration of wave data is  50ms, interval : 0ms    (  0ms buffer + 50ms new data)
    [process rdp data] process 25 ms
    [get Wave PDU]  duration of wave data is  50ms, interval : 30ms  (20ms buffer + 50ms new data)
    [process rdp data] process 55 ms
    [get Wave PDU]  duration of wave data is  50ms, interval : 60ms  (10ms buffer + 50ms new data)
    [process rdp data] process 45 ms
    [get Wave PDU]  duration of wave data is  50ms, interval : 40ms  (20ms buffer + 50ms new data)

    in Log1, the audio data shows well. and

    Log 2.
    [get Wave PDU (A)]  duration of wave data is  50ms, interval : 0ms    (  0ms buffer + 50ms new data)
    [process rdp data] process 25 ms
    [get Wave PDU (B)]  duration of wave data is  50ms, interval : 30ms  (20ms buffer + 50ms new data)
    [process rdp data] process 30 ms
    [process rdp data] process 35 ms
    [get Wave PDU (C)]  duration of wave data is  50ms, interval : 70ms  (  0ms buffer + 50ms new data)
    [process rdp data] process 55 ms
    [process rdp data] process 55 ms
    [get Wave PDU (D)]  duration of wave data is  50ms, interval : 120ms( underrun occured )

    in Log2, audio buffer underrun occured.

     

    Thursday, June 16, 2011 10:10 AM
  • Hi CSaint,

     

    After you receive a Wave PDU, you are sending a Wave Confirm PDU.  In the Confirm PDU, how are you setting the wTimestamp?

     

    [MS-RDPEA] 3.2.5.2.1.6 “Sending a Wave Confirm PDU” specifies that the client MUST send the Wave Confirm PDU immediately after consuming the audio data and that the “wTimeStamp field MUST be set to [ … ... ] plus the time, in milliseconds, between receiving the packet from the network and sending this PDU. This enables the server to calculate the amount of time it takes for the client to receive the audio data PDU and send the confirmation.”  Consuming the audio packet includes actually playing the packet.  Therefore, “plus the time, in milliseconds, between receiving the packet from the network and sending this PDU” should include the play time.

     

    I suspect that your wTimeStamp does not include this extra time and, therefore, the server is miscalculating when to send the next wave.

     

    Please let me know if this suspicion is correct and if adding this time resolves your issue.  I discussed this with the [MS-RDPEA] team and filed a request with the specifications team to make this more clear.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Friday, June 17, 2011 2:08 AM
    Moderator
  • Hi Bryan,

    Thanks for your reply.

    I try to change the return value of wTimeStamp, and it can play mp3 files smoothly.  But, if I play clips on youtube or video files, 
    sometimes the audio is still choppy.

    I calculate the average interval between each Wave PDUs, the interval is 49~50ms per 1000 Wave PDUs.
    The average is very nice but buffer underrun still occured.  

    Therefore, I look into these PDUs, I find that the average interval fluctuate between PDUs.

    If the interval over 50ms for a while, the underrun occured.

     

    I think your suggestion solved my question, but there might be other issues of the protocol [MS-RDPEA] and [MS-RDPRFX], maybe the server scheduling of sending video PDU and wave PDU, or performance issue.

     

    Monday, June 20, 2011 9:22 AM
  • Hi, CSaint,

     

    You should report the actual timestamp for every PDU (via Wave Confirm PDUs), not just return an average.  This allows the server to adjust to changing network conditions.  Since your original question was solved, I’ll resolve this issue.  If you have other issues after changing your code to respond with actual timestamps instead of average timestamps, please let us know.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Monday, June 20, 2011 10:36 PM
    Moderator
  • Hi Bryan,

     Yes, I had reported the actual timestamp.

     Average intervals were just used for my observation.

     

    Tuesday, June 21, 2011 2:51 AM
  • Hi, CSaint,

     

    Let me insure I understand.  You had an issue that was common where audio was usually choppy.  You added the play time to your timestamps per my suggestion and now the original issue is resolved regarding MP3.  But, you are now reporting an issue with audio that accompanies video.  While audio with MP3 went from usually choppy to good.  Did video also improve with the timestamp change or is it about the same?  Your initial audio issue was reported in the context of a lower performance client or low bandwidth connection.  Is this the same scenario with your video issue.  I’m trying to determine if this is a protocol problem or a performance issue.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Tuesday, June 21, 2011 5:11 AM
    Moderator
  • Hi Bryan, 

       Yes, the scenario is the same, and timestamps I reported were the same as your suggestion while I played video.

       The situation could be improved if I changed the Screen capture rate and Screen Image quality from Highest to Medium.

       These configurations could be found in http://technet.microsoft.com/zh-tw/library/gg288964(WS.10).aspx.

     

    Monday, June 27, 2011 2:39 AM
  • CSaint,

     

    Can you contact me offline via "Dochelp (at) microsoft (dot) com" and  supply exact details of your scenario?  I'm collaborating directly with the RDP team.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Thursday, June 30, 2011 5:50 AM
    Moderator
  • CSaint,

     

    I didn’t see a response to this issue via either “dochelp (at) microsoft (dot) com” or this forum thread.  Was it resolved?  I’m going to close this on our end.  But, if this still requires attention, please contact us.

     

    Bryan


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team
    Tuesday, July 19, 2011 7:22 PM
    Moderator