The Windows shared-mode audio engine operates entirely in floating-point mode.
It also has a limiter. This includes MME shared mode, DirectSound shared mode,
Media Foundation shared mode, and WASAPI shared mode. It does not include MME
exclusive mode, DirectSound exclusive mode, Media Foundation exclusive mode, or
WASAPI exclusive mode.
(But please don’t use exclusive mode.)
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, August 21, 2018 11:47:50 AM
Subject: [wdmaudiodev] bit transparency from app to WDM audio driver depending
I’ve written a little application (based on PortAudio) which can use the
different APIs (MME, DirectSound, WASAPI or WDM Kernel Streaming) to play audio
to my WDM driver. Now when I play a 16 bit ramp (increasing the samples one by
one), I can watch in my driver that the arriving samples don’t increase one by
one, but it’s OK for some samples, then suddenly the same value is received
twice and afterwards one value is skipped. This is not the case when my app
uses the WDM Kernel Streaming API, then every sample shows the expected value.
But I can see it for the other three APIs. I’ve ensured that there’s no
dithering in my app and the samples sent by my app are steadily increasing.
This looks to me like there’s a SRC or a format conversion
(short->float->short) which adds dithering when I’m using MME, DirectSound or
WASAPI? While I’m aware of the windows mixer (audiodg.exe) being active for MME
and DirectSound, at least for WASAPI I thought it should be bit transparent?
Does the windows mixer always add a SRC or dithering?
Thanks and best regards,