[wdmaudiodev] Re: Sample Rate Negotiations

  • From: Wade Dawson <Wade.Dawson@xxxxxxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 20 May 2020 12:36:20 +0000

Hi Ed.  Very nice write-up.  What OS version is your target?

I can't tell you exactly what's happening in your case (except for a lot 
frustration I'm sure), but I found that I wasn't properly handling the case 
where the PD's GET requests were sent with a zero buffer length to query the 
format size.  I was getting storms much like you describe.

Probably not your issue, but worth a mention.  I really wish we could could 
have the same source visibility of the Audio Engine that we enjoy for WDF!!

Best of luck!
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on 
behalf of Edward Tottenham <edward@xxxxxxxxxxxxxx>
Sent: Tuesday, May 19, 2020 3:30 PM
To: wdmaudiodev@xxxxxxxxxxxxx <wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Sample Rate Negotiations

Hello, I apologise in advance for the wordiness of this e-mail. I'm hoping you 
can help .

I am still having problems with the negotiations over sample rate and 
resolution in a WavePCI Miniport driver.

The device is connected via USB and the audio passes through a Lower Driver 
which handles the Isochronous USB traffic. It has 5 pairs of inputs (Wave pins 
0, 2, 4, 6, 8) and 6 pairs of outputs (Wave pins 18, 20, 22, 24, 26, 28).

The device itself MUST control the sample rate and resolution, it has controls 
on the actual device.

The following is the behaviour that I see. In this case, the device was at 
44k1, 24-bit when attached to the computer.

When the driver is first loaded and the device is connected, the driver sends a 
KSEVENT_PINCAPS_FORMATCHANGE event for each Wave Pin to the Port Driver.

The Miniport Driver receives, and forwards, a series of Format Change events, 
one for each pin.

The Port Driver sends a Get Format request for the first Wave Pin and my 
MiniPort Driver responds with a preferred setting of 2-channel, 44k1, 24-bit.
The Port Driver proposes the format 2-channel, 44k1, 24-bit for the pin, my 
Miniport driver accepts.
The Port Driver sends SetFormat, 2-channel, 44k1, 24-bit, for the pin and my 
miniport driver returns success.
The Port Driver again sends a Get Format request for the first Wave Pin and my 
MiniPort Driver responds with a preferred setting of 2-channel, 44k1, 24-bit.

The Port Driver now proceeds to propose every possible combination of 1 or 2 
channels, at 44k1/48k/88k2/96k/176k4/192k with 16/24/32 bits. (35 formats in 

Question 1). Why does it propose all of these, we've already set the format?
Question 2). My Data Ranges specify 2 channels as both Minimum and Maximum and 
Minimum 16-bit, Maximum 24-bit, so why are the 1 channel formats and 32-bit 
formats proposed?

From experience; if I accept any of these proposals, the Port Driver will try 
to set that format. I must therefore reject them all.

This whole negotiation is repeated for the remaining 10 Wave Pins.

Question 3). The total time for this to happen is 22 seconds, is this normal?

The Port Driver then continues to send the whole sequence of 35 format 
proposals for a Wave Pin, roughly one pin every 4 or 5 seconds. This seems to 
continue until I play the test tone, when it calms down.

The behaviour is further complicated if the deice is now disconnected from the 
computer, used on another computer and then brought back again but set at a 
different sample rate, in this case 192k, 24 bit.

It is the device which should be dictating the Sample Rate, so it will try to 
use 192k.

My driver, again sends the KSEVENT_PINCAPS_FORMATCHANGE event for each of the 
11 Wave Pins.
The Miniport Driver receives, and forwards, a series of Format Change events, 
one for each pin.
The Port Driver sends a Get Format request for the first Wave Pin and my 
MiniPort Driver responds with a preferred setting of 2-channel, 192k, 24-bit.
The Port Driver Proposes 2 Channel, 44k1, 24-Bit for a total of 57 times over 
the next 2.5 seconds.

Question 4). Having sent the Get Format request to find the preferred format, 
why does it propose a different format? Is it because this was the last format 
used by the device?

The Port Driver again sends a Get Format request for the first Wave Pin and my 
MiniPort Driver responds with a preferred setting of 2-channel, 192k, 24-bit.
The Port Driver proposes combinations of 2 or 6 channel, 44k1 or 48k at 16, 24 
and 32-bit. (I'm not sure where the idea of 6-channel came from).
The DataRangeIntersection() function in my Miniport Driver is called. 
2-channel, 192K and 24-bit exist in both data ranges so the resultant format 
specifies 2-channel, 192k, 24-bit.

The Port Driver again sends a Get Format request for the first Wave Pin and my 
MiniPort Driver again responds with a preferred setting of 2-channel, 192k, 

The Port Driver again proposes all combinations of 2 or 6 channel, 44k1 or 48k 
at 16, 24 and 32-bit.

The DataRangeIntersection() function in my Miniport Driver is called again. 
2-channel, 192K and 24-bit exist in both data ranges so the resultant format 
specifies 2-channel, 192k, 24-bit.
The port driver proposes 2-channel, 16-bit at 22050, 24000, 32000, 44100, 
48000, 88200, 96000, 176400, and 192000.
My Miniport driver refuses all of these as they are not 24-bit.

No further negotiations take place.  The device is unusable.

This remains the situation until I change the sample rate on the device itself, 
this resends the KSEVENT_PINCAPS_FORMATCHANGE events and eventually the format 
is negotiated correctly, although there are still a lot of invalid proposals.

I guess that the big question is: Can this be achieved without such long 
negotiations, particularly since 2/3 of the formats proposed are invalid 
according the the Data Ranges specified by the driver?

Is there any tool which might help in understanding what is happening? The 
driver is just about usable, except in the case where the device has been used 
on a different computer and returned at a different sample rate.

I appreciate that my driver is probably incorrecty written and hence is the 
cause of most of these problems, but I can't quite see where. Knowing why the 
Port Driver behaves the way it does might help to understand the failings in my 

Best wishes
Ed Tottenham
****************** 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: ;

Other related posts: