Sorry, I missed that you were using exclusive mode. That’s probably why you’re
not getting the flag.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 12, 2018 12:28:24 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] AW: bit transparency when recording from WASAPI vs.
WDM-KS (both exclusive mode)
Thanks for the link.
As written in my first post, I’m quite sure I did check the Flags and it has
always been 0 and so AUDCLNT_BUFFERFLAGS_DATA_DISCONTINUITY has not been set.
And I also checked the value of DevicePosition and it is incremented as if the
wrong bunch of samples would be valid. So I don’t see any way to detect this
problem, except knowing the audio data which should be delivered. I could
restore the previous sources and repeat my tests, if you’re interested in the
result.
Here’s a little example of the sample ramp I’m receiving:
… 8000 8001 8002 8004 6853 6854 6855 6856 6857 | 8010 8011 8012
- the number of wrong samples varies between about 30 and 200 (in my example
it’s only 5 wrong samples)
- it always jumps back the value of 1152 compared to the expected sample
- it always jumps back somewhere in the middle of a buffer
- it resets to the original row at the first sample of the next call to
GetBuffer() (in my example signaled by the pipe symbol)
- it happens for the first time about 48 minutes after I started the recording,
then again after some minutes
It’s not only about my application as this is not what I’m going to give away
to customers. But the driver is part of our product and our customers are
writing applications themselves, sometimes based on portaudio or on their own
sources and it’s hard to argue that they shouldn’t use WASAPI in this or that
way when they don’t see any error or Flag set in their implementation after a
call to a WASAPI function. Probably they’d be first going to blame our driver
if they detect glitches etc..
Von: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 12. September 2018 17:05
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev] Re: AW: bit transparency when recording from WASAPI vs.
WDM-KS (both exclusive mode)
A better sample is here:
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WindowsAudioSession<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FWindows-universal-samples%2Ftree%2Fmaster%2FSamples%2FWindowsAudioSession&data=02%7C01%7Cmatthew.van.eerde%40microsoft.com%7C20e26e074e074383c18608d618e5fcf4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636723773434838058&sdata=xWty1ViEFo1Km4Bt1nroe5tm8fV9RUVDI%2BvaNrRE93M%3D&reserved=0>
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<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, September 12, 2018 5:41:04 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto: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%7C20e26e074e074383c18608d618e5fcf4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636723773434838058&sdata=f2uo8tyQHGEBVK6DJ6hBk%2FGi5ehnhY%2BZmLUlSitZ4pE%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<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Gesendet: Dienstag, 11. September 2018 17:41
An: 'wdmaudiodev@xxxxxxxxxxxxx'
<wdmaudiodev@xxxxxxxxxxxxx<mailto: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
