[wdmaudiodev] Re: Issue with AVStream audio renderer
- From: Tim Roberts <timr@xxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 12 Apr 2011 09:24:15 -0700
Mike Horgan wrote:
>
> I am developing an AVStream miniDriver (WDM) which is exposing two
> filters:
>
>
>
> Audio capture filter
>
> Audio renderer filter
>
>
>
> The audio device itself is a USB device.
>
>
>
> The capture filter seems to be functioning. I can drop that filter
> into GraphEdit and render it’s output pin to Default DirectSound
> Device and play the graph. I have a signal generator driving the
> input of my audio device and when the graph is running I can hear the
> tone on the speakers. The state of everything seems fine since I can
> use the GraphEdit buttons to start/stop/pause/start/stop the graph.
>
>
>
> The render filter I worked on next. Right now it’s Process() method
> just dumps any audio it gets on the floor. It does this by
> KsStreamPointerAdvanceOffsets()’ing the leading edge everytime it gets
> called.
>
>
>
> I can drop both filters into GraphEdit and if I render the output pin
> of the capture filter, it connects right up to the input pin of my
> render filter. However, if I start the graph the start button stays
> depressed and I don’t see the stop button in the UI go red. From
> debugging (and logging) I see the capture filter preload all the
> allocator frames with audio from the device and then the render filter
> moves from “pause” to “run”. The capture filter moved through the
> states to run at the beginning and the render filter moved all the way
> to “pause”. The logs show that render filter is continually fed
> stream pointers and the addresses match the order that the capture
> filter filled them. The capture filter continues to get called and
> fills buffers so it seems at one level the graph is running.
>
How are you handling the pacing and timestamping here? Is your capture
filter actually reading from your device? (And if so, why is your
device not USB Audio Class compliant so you can user usbaudio.sys?) Are
you blocking to wait for the capture device to deliver data?
Here's example. If you were producing fake data in your capture filter
with no timing considerations, and you were sucking up the data in your
render filter with no timing considerations, the two filters would
communicate as fast as possible, in kernel mode, using 100% CPU, while
doing absolutely nothing.
Is your capture filter putting timestamps on the packets? Is your
render filter handling timestamps?
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
