You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the MME Host API code only creates 16-bit integer MME
buffers. All audio data provided by the user is therefore converted by
PortAudio to and from 16-bit, regardless of the user buffer format.
This basically makes it impossible to pass 24-bit audio through the
MME Host API.
If the user buffer format is not 16-bit, this also causes pointless
conversions to take place, *even if the hardware is running at 16-bit*,
because modern Windows versions (Vista+) convert the data to floating
point behind the scenes before it is handed off to the hardware. This
can lead to silly situations where 32-bit float samples from the user
are (lossily) converted to 16-bit by PortAudio, then ended off to
Windows via MME, only to be converted back to 32-bit float again, before
finally being converted to the format the hardware device is configured
to use. This can easily lead to two layers of 16-bit dithering (one from
PortAudio, and one from Windows) being piled on top of each other,
resulting in an elevated noise floor.
This commit fixes this problem by configuring the MME buffers to use the
same format as the user buffer. This should stop PortAudio from
converting samples in all cases except paInt8, which is not supported by
WAVEFORMATEX (only paUInt8 is). This is pretty much the same idea as
#774.
The new code assumes that MME will accept whatever format we throw at
it. I feel confident that this is always true on Vista+ regardless of
hardware, because starting from Vista MME does not access hardware
directly - it always goes through the Windows Audio Engine which
supports all formats in both directions (I verified this using
paloopback).
On pre-Vista Windows, this should still work all the way back to Windows
98 SE, because MME goes through KMixer which supports all formats [1].
Nevertheless, it's difficult to be sure, so this code checks the Windows
version it's running on and preserves the old behavior (i.e. always use
Int16) on pre-Vista Windows.
[1]: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/background-of-non-pcm-support#waveout-apiFixes#139
unsigned longoutputDeviceCount=0; /* contains all devices and channel counts as local host api ids, even when PaWinMmeUseMultipleDevices is not used */
2330
2332
charthrottleProcessingThreadOnOverload=1;
2331
2333
2334
+
/* On Windows Vista and greater, MME will accept any format that can be represented
2335
+
in WAVEFORMATEX and will internally convert if and when necessary.
2336
+
On older Windows versions, the story is less clear, so we restrict ourselves to
0 commit comments