Hi all,
currently I'm doing some further tests with my pure virtual audio driver.
The samples transferred to the recording application are generated inside my
driver and it's a simple ramp meaning the 16 bit samples are always
increased by +1.
My recording app is based on latest portaudio library and it checks whether
each sample delivered from the driver is the previous one + 1. This works
perfect all the time when I'm using WDM Kernel-Streaming as API in my
recording app.
When I use WASAPI exclusive mode for recording it works correct for about 47
minutes. Then the expected value is not received but the expected value
minus 1152. I will receive samples growing by one for a while (like 30 or
150 samples), then there's again a break and the value jumps back to the
value corresponding to the row before the first break (so it jumps forth
1152 plus the number of samples since the first break). So it seems like
there's bunch of samples delivered from a wrong and older buffer. The number
of wrong samples seems to vary between about 30 and 200. But the difference
to the expected sample seems to be always 1152. I'm checking the content of
the buffer right after my call to IAudioCaptureClient::GetBuffer() (I'm
checking result is S_OK and flags is 0). The start of the wrong bunch of
samples seems to be always somewhere in the middle of a buffer returned by
IAudioCaptureClient::GetBuffer() while the return to the expected value
always starts at the beginning of the next IAudioCaptureClient::GetBuffer().
So to me it looks there's still some old data at the end of the buffer
returned by IAudioCaptureClient::GetBuffer()? The number of samples I'm
requesting in GetBuffer() is the number returned by
IAudioClient::GetCurrentPadding() with result = S_OK directly before the
GetBuffer() call.
Is this something which could be a problem inside my driver although it
works correct when using WDM Kernel-Streaming?
Thanks and best regards,
Johannes
