[wdmaudiodev] Re: Device Formats

  • From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 22 Sep 2017 20:37:36 +0000

The engine learns of your preferred format by doing a 
KSPROPERTY_PIN_PROPOSEDATAFORMAT/GET request, if you advertise support for GET 
in your basic support handler. No attention is paid to the order of the formats 
in your data format table.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on 
behalf of Tim Roberts <timr@xxxxxxxxx>
Sent: Friday, September 22, 2017 1:03:21 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Device Formats

I am confused about format handling in a WaveRT device.

I started from the Windows 8.1 version of the SysVAD sample.  I have
removed all of the advertised formats except for 48000-Mono-16 for the
microphone, and 48000-Stereo-16 for the speaker.  This works just fine.
I'm currently testing with GraphEdt playing back a WAV file, and my mic
going to speakers.  I created a simple circular buffer to pass from fake
speaker to fake mic, and with a stereo-to-mono conversion, the sound
does pass through.

But if I change the speaker to 48000-Mono-16, things do not work.  The
audio engine tells me it's going to send 48000-Stereo-16, which I "no
match", and it never offers 48000-Mono-16, even though that is the only
format in my tables.

Even worse, if I change the format from PCM16 to IEEE_FLOAT (which is
what I eventually want), I can create the filter in graphedt, but it has
no pins.  I thought float32 was the preferred format for the Audio
Engine, so I expected this to work.

I thought the Engine learned of my preferred format by using the first
item in my KSDATAFORMAT table.  Why is it sending me formats that aren't
in my table?  How does this negotiation happen?  I don't see any other
properties that send a "default format".  The only calls to
KSPROPERTY_PIN_PROPOSEDDATAFORMAT I get are all SET calls that I reject,
because the value buffer is too small.

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: