[wdmaudiodev] Re: Problem running an AVStream audio capture filter under XP
- From: Mike Horgan <mhorgan@xxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Fri, 8 Jul 2011 12:56:00 -0700
I wondering whether the problem I'm having stems from not implementing a
particular property. Currently my filter doesn't define an automation table
and when I select my hardware from within the DAW, the only failure I see is in
response to KSPROPERTY_PIN_GLOBALCINSTANCES. The documentation for that
property seems to indicate that it is optional but I'm wondering whether that
is really true.
I've looked at the public domain zaudio driver and they support that property,
along with a number of other properties. Is there some unwritten rule which
states which properties are in fact essential? Is it conceivable that
something like a missing property like this could lead to graph which runs fine
in Win7, but fails in XP?
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Horgan
Sent: Friday, July 08, 2011 10:20 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Problem running an AVStream audio capture filter
under XP
I do specify that flag in the descriptor
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: Thursday, July 07, 2011 7:56 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Problem running an AVStream audio capture filter
under XP
Mike Horgan wrote:
If I install this same driver under XP sp3 and launch Reaper I again see that
the device is enumerating under WDM Kernel Streaming system. If I select the
device and try to record, the cursor just seems to sit at time "0". Under the
debugger I see the capture pin get instanced and the system changes the state
of the pin from KSSTATE_STOP to KSSTATE_ACQUIRE, but it goes no further. I've
verified that the state change to acquire returns success so I'm a bit baffled
as to what is wrong. If I run GraphEdit and instance the capture filter, I can
smart render the pin (it connects up to default DS renderer) and run the graph
and actually hear the tone from my generator.
I'm at a loss to explain what it is that the XP audio system doesn't like about
the filter. Neither the filter, nor the pin are exposing an automation table.
I'm just letting the AVStream framework handle any properties. I don't see the
system querying for any audio specific properties (latency, position) which
would lead me to believe that maybe I need to include one or more.
Do you have KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY set in the pin descriptor?
Ordinarily, the graph wants to get the first chunk of data while it's in
"acquire" state, so that it is ready to go immediately on the transition to
"run". When that happens, the graph does not transition to "run" until it has
at least one sample. This is very useful for video devices (so you get a
poster frame), but not so much for audio.
The IN_RUN_STATE_ONLY flag should suppress that behavior. It is equivalent to
the VFW_S_CANT_CUE return in a DirectShow source filter.
--
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.
Other related posts:
