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