A better sample is here:
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WindowsAudioSession
It uses work queues with event-triggered work items, rather than Sleep or
WaitForSingleObject.
You can look at the “flags” output parameter to IAudioCaptureClient::GetBuffer
to see if there was a glitch; if so, the “data discontinuity” flag will be set.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 12, 2018 5:41:04 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] AW: bit transparency when recording from WASAPI vs.
WDM-KS (both exclusive mode)
OK, now I changed the WASAPI loop in my recording app according to the example
at
https://docs.microsoft.com/de-de/windows/desktop/CoreAudio/capturing-a-stream<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fde-de%2Fwindows%2Fdesktop%2FCoreAudio%2Fcapturing-a-stream&data=02%7C01%7Cmatthew.van.eerde%40microsoft.com%7C15832418f1fb469af32e08d618ad15a1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636723529048954809&sdata=HQ8UQbkWtvFQtNp0UUIZ5TumUNXMWiL0nZvnOsX2hoE%3D&reserved=0>
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?
Best,
Johannes
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 exclusive
mode)
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
