[wdmaudiodev] Re: Kernel streaming question
- From: Pallavi Joshi <pallavi.v.joshi@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Thu, 25 Jun 2009 16:32:44 -0700
Hi Tim,
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;
}
Please let me know if you have any suggestions.
Thanks,
Pallavi
On Wed, Jun 24, 2009 at 1:49 PM, Pallavi Joshi <pallavi.v.joshi@xxxxxxxxx>wrote:
> Okay I will try to implement that. Will let you know how it goes.
>
> Thanks very much for your help.
>
> Pallavi
>
>
>
> On Wed, Jun 24, 2009 at 11:29 AM, Tim Roberts <timr@xxxxxxxxx> wrote:
>
>> Pallavi Joshi wrote:
>> > Yes, it makes sense. I measured the time it takes for my function to
>> > input data(256 samples). It takes around 16 ms whereas it should be
>> > taking like ~6 ms. I do not know why that is the case. This is only
>> > true with USB. With the laptop's default audio card it takes ~6 ms.
>> >
>> > The data comes from the USB's audio capture pin. I have connected a
>> > MP3 player to the stereo input of my USB audio device....that's where
>> > the input data comes from.
>> >
>> > May be the input takes more time because USB operation is slow...is
>> > that a possibility?
>>
>> 16ms sounds suspiciously like you are waiting to be rescheduled.
>>
>> Again, remember that this is a real-time path. There is no buffering.
>> If you ask for 256 samples (1024 bytes, right?), your request gets sent
>> down the stack, the buffer is filled and returned, but nothing else can
>> happen until you send down a new buffer. During the time between your
>> request being filled and you shipping an empty buffer back down, audio
>> data is being lost.
>>
>> You need to have several buffers going at once. That is, submit 3 or 4
>> read requests all at once. As each is returned, you can process it and
>> return it, but while you are playing around, your next buffer is being
>> filled.
>>
>> --
>> 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
>>
>> URL to WDMAUDIODEV page:
>> http://www.wdmaudiodev.com/
>>
>>
>
>
> --
> Pallavi Joshi
> (480)-280-2017
>
--
Pallavi Joshi
(480)-280-2017
Other related posts:
