OK, now I changed the WASAPI loop in my recording app according to the
m and now I cannot watch these breaks in the ramp anymore. That's fine and
so it's probably been no driver issue.
The difference to the previous implementation in the recording app is mainly
the timeout for Sleep() or WaitForSingleObject() which was set to 0 in the
original sources and the use of IAudioClient::GetCurrentPadding() which is
now done by IAudioCaptureClient::GetNextPacketSize(). But as there were no
errors returned by IAudioClient calls in the original version and everything
seemed to work fine, if I hadn't checked the audio data itself, I'm not sure
if everything works as expected inside WASAPI?
Von: Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Gesendet: Dienstag, 11. September 2018 17:41
An: 'wdmaudiodev@xxxxxxxxxxxxx' <wdmaudiodev@xxxxxxxxxxxxx>
Betreff: bit transparency when recording from WASAPI vs. WDM-KS (both
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
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
Is this something which could be a problem inside my driver although it
works correct when using WDM Kernel-Streaming?
Thanks and best regards,