[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
configuration.
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
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts: