[wdmaudiodev] AW: bit transparency when recording from WASAPI vs. WDM-KS (both exclusive mode)
- From: "Johannes Freyberger" <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Wed, 12 Sep 2018 21:28:24 +0200
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/W
indowsAudioSession
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-strea
m
<
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.micro
soft.com%2Fde-de%2Fwindows%2Fdesktop%2FCoreAudio%2Fcapturing-a-stream&data=0
2%7C01%7Cmatthew.van.eerde%40microsoft.com%7C15832418f1fb469af32e08d618ad15a
1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636723529048954809&sdata=HQ8U
QbkWtvFQtNp0UUIZ5TumUNXMWiL0nZvnOsX2hoE%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
Other related posts:
