[wdmaudiodev] Re: Kernel streaming question

  • From: Pallavi Joshi <pallavi.v.joshi@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Thu, 25 Jun 2009 17:17:33 -0700

Yes, hEventPoolIn is the event I pass in the overlapped structure to my
DeviceIoControl function. I am not using 5 ms timeout always. I was just
playing with several values. I have tried many other values larger than 10
or 16 ms but there is no change.

No, I am not doing a loopback. I take the input data, process it i.e.
separate the multi channel data into 2 separate channels and then give it to
the host application which fills in my output buffers. These output buffers
are then sent to the render pin (again using DeviceIoControl and

As you must have realized, all this is done inside an audio driver that I am

Thanks again for your help,

On Thu, Jun 25, 2009 at 4:54 PM, Tim Roberts <timr@xxxxxxxxx> wrote:

>  Pallavi Joshi wrote:
> I just wanted to give you more information about that 16 ms time taken to
> read data from the capture pin. For inputing the data, I am using the
> DeviceIoControl function with IOCTL_KS_READ_STREAM as the control code. This
> operation is sent as a asynchronous operation but when it returns I do not
> exit my input function until the read operation is complete. This is done
> using a WaitForSingleObject function. Thus my input is synchronous. This
> operation is done in the correct amount of time for my laptop audio card but
> for the USB it is very slow. Do you think that the WaitForSingleObject might
> be delaying things for me? Is there any other way that you recommend in
> place of WaitForSingleObject? This is how my code looks:
> hr = CPin->ReadData(&PacketsIn.Header, &PacketsIn.Signal);  // This
> function calls DeviceIoControl with the arguments
> DWORD dwWait; if (SUCCEEDED(hr))
> {
> dwWait = WaitForSingleObject(hEventPoolIn,5);
> if ((dwWait == WAIT_FAILED) || (dwWait == WAIT_TIMEOUT))
> hr = E_FAIL;
> }
> Who is triggering hEventPoolIn?  Is that the event you pass in the
> OVERLAPPED structure?  Remember that a user-mode app cannot wait for just 5
> ms.  The minimum wait period is the scheduler interval, which is either 10
> ms or 16 ms, depending on your system.  Also, usbaudio.sys sends 10 ms worth
> of buffers when it goes to read from the device.
> Are you trying to do a loopback -- just copy from input device to output
> device?  Input from a USB device suffers from the same issues as output to a
> USB device.  If you do not have buffers ready and waiting to be filled at
> all times, incoming data will be lost.
> You're going to need to think about having multiple read requests
> outstanding at any one time.
> There have to be people on this list with recent experience in DirectKS.
> Have any advice for Mr. Joshi?
> --
> Tim Roberts, timr@xxxxxxxxx
> Providenza & Boekelheide, Inc.

Pallavi Joshi

Other related posts: