[wdmaudiodev] Re: Audio dropouts with simple filter graph.

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 19 Mar 2019 17:26:41 +0000

Grab audio glitching logs of the problem in action: 
https://blogs.msdn.microsoft.com/matthew_van_eerde/2017/01/09/collecting-audio-logs-the-old-fashioned-way/



________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on 
behalf of Tom Eckert <teckert@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 19, 2019 10:18:35 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Audio dropouts with simple filter graph.

We have an issue discovered by a customer who is using a DirectShow
filter graph to provide a monitor stream and we've been able to
duplicate the behavior with GraphStudioNext.

After running clean for about 40 minutes we start to hear audio
dropouts.  Our debug log shows that the player stream is paused and
resumed.  This coincides with increased CPU utilization (but it didn't
go over 50%).

I've attached a screenshot of the graph plus the timing log we generated
during the test.

At first, I assumed that the thread handling the read from the record
side fell behind and the play stream had to be paused briefly to prevent
underflow.  But the log shows that prior to the pause the CopyFrom calls
are spot on.  Also, the CopyTo's are about 20 ms ahead of the play
pointer just as they are when it's playing clean.

Has anyone experienced similar behavior?  Or can you suggest what driver
behavior might be causing the graph to pause/resume like this.

Thanks and regards,
Tom

Thomas Eckert
AudioScience, Inc


Other related posts: