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/