[wdmaudiodev] Re: AVStream: sound quality depends on the usage, why?

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 28 Jun 2016 17:33:03 -0700

alexander ivash wrote:

Incorrect format usage is really the simplest explanation for sound  
distortion and this is what I'll check. But what is not clear for me, is  
why even in graphedit the same filter sounds differently if selected as  
'WDM Capture' (good) and 'Audio Capture' (delayed, cropped). Could it be  
the case that 'mic' bridge pin introduces its own delays? I hope it is  
not, because I thought it is required only to make sysvad happy and should  
have no any impact on the overall performance..

No, the topology does not get involved in streaming.  It's just for

I'm still using DPC (like in original avssamp), which calls  
KsFilterAttemptProcessing every tick, and probably there are no any  
reasons to continue using it.. But it worked fine until I registered  
driver as virtual mic so haven't changed that part yet.

What does that driver use for ticks?

Here's what I'm trying to say.  You might assume, if you were asked to
provide a 48kHz mono 16-bit stream, that you could simply shove out 96k
bytes as soon as you had them, and the rest of the pipeline would expect
that to take 1 second.  It ain't necessarily so.  If you shove data out
as fast as you get empty buffers in, there are parts that will try to
play it faster than real time, and thereby end up with gaps.  You have
to take some care to deliver packets in a regular cadence.

Probably this is suboptimal or even wrong, but still not clear why does it  
work in one scenario and doesn't in other.

My guess is the two methods trigger different clock bases.  If the graph
depends on your driver as the master clock source, it's not going to get
a nice, reliable, hardware-generated clock.

By the way, if I decide to get  
rid of DPC / KsFilterAttemptProcessing, what is the other mechanism of  
triggering Filter::Process ?

By default, Process is triggered any time another empty buffer arrives
at your input pin.

Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.


WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx


Other related posts: