WDM-KS malfunction on Windows XP in 19.07 latest stable release

[ijgnaig]

Describe the bug Sound device: ICH5 AC97 controller + AD1980 AC97 codec The WDM-KS hostapi in release pa_stable_v190700_20210406.tgz is malfunctioning on Windows XP: stream playback speed is nearly 4 times faster than normal, recording stops immediately and generates empty files.

To Reproduce

1. Download the stable release, configure it using cmake, disabling all hostapis except WDM-KS
2. Build with i686-w64-mingw toolchain
3. Link a program which can play/record to files, or use the included sine wave test program just for playback test
4. Run the test program

Expected behavior Stream plays at normal speed, default input source can be recorded.

Actual behavior Playback speed is nearly 4 times faster than normal, audio is completely distorted, regardless of sample rate and bit depth. Recording stops immediately and if saved, the file is empty. No crash, no error message generated. CPU and memory usage are like normal.

Desktop (please complete the following information):

• OS: Windows XP 32 bit
• OS Version: Server Pack 3
• PortAudio version: 19.7.0 latest stable release
• If Windows or Linux, which Host API (e.g. WASAPI): WDM-KS only

Additional context This problem afftects any program built for Windows XP using the release, like Audacity (non-official personal builds). WMME, DS and ASIO do not exhibit the problem.

[ijgnaig]

After some tests, the last stable release that works flawlessly on Windows XP appears to be "pa_stable_v19_20140130.tgz released January 30, 2014, SVN rev 1919"

[RossBencina]

@ijgnaig thanks for the report. Could you please clarify: what was the oldest stable release that failed?

I'm guessing that it was one of these commits that broke it:

April 10, 2014: https://github.com/PortAudio/portaudio/commit/4aa340a57e98e1bfd7f3ab1449226de76ed8f9aa

Aug 15, 2014: https://github.com/PortAudio/portaudio/commit/d7085cb226fb8d2974e281b3ea25d89a401d85c3

Aug 28, 2014 https://github.com/PortAudio/portaudio/commit/6733684fcaf0efd2c12b8b0a21ba6fad3dc015f7

It would be good to work out which commit broke it before reviewing them in detail. Would you be able to do a git bisect?

[RossBencina]

Is there any chance you could test the same hardware with a more recent Windows version?

[ijgnaig]

@RossBencina Sorry for the late response, the oldest stable release is January 30, 2014, SVN rev 1919 and was tested natively on my hardware, it didn't exhibit that problem. Upgrading Windows from XP might be possible, but if I remember correctly, PA forces WaveRT event notification mode instead of classic Kernel Streaming polling mode, which is used on XP, when we are using Vista and above:

/* If WaveRT, check if pin supports notification mode */
    if (parentFilter->devInfo.streamingType == Type_kWaveRT)
    {
        BOOL bSupportsNotification = FALSE;
        if (PinQueryNotificationSupport(pin, &bSupportsNotification) == paNoError)
        {
            pin->pinKsSubType = bSupportsNotification ? SubType_kNotification : SubType_kPolled;
        }
    }

        if (pPin->pinKsSubType != SubType_kPolled)
        {
            /* In case of unknown (or notification), we try both modes */
            result = PinGetBufferWithNotification(pPin, pBuffer, pRequestedBufSize, pbCallMemBarrier);
            if (result == paNoError)
            {
                PA_DEBUG(("PinGetBuffer: SubType_kNotification\n"));
                pPin->pinKsSubType = SubType_kNotification;
                break;
            }
        }

So I think the problematic code shouldn't be exclusive to WaveRT part and it's best to stay on native XP, right?

[RossBencina]

@ijgnaig: can you check the git versions that I listed please?

[ijgnaig]

@RossBencina Now I've tested all 3 commits, none of them have that problem. Then I tested both that stable archive and development branch, they are all fine. Maybe this bug is hardware related? Because currently I don't have access to my old machine so I'm using Windows XP under VirtualBox.

[RossBencina]

@ijgnaig: thanks for testing. The thing is, the WDM-KS code will use different code paths depending on the driver buffering model, so unless VirtualBox driver uses the same buffering model as your hardware you may not even be testing the same code paths. If you have a chance to re-run the test of each commit on the original hardware, please do so.

[ijgnaig]

@RossBencina Hi, now I got a chance to test all these commits on that original pc: 4aa340a, d7085cb and 6733684, none of them has any playback problem. I built them under msys2 with cmake and ninja, then statically linked this simple player againt portaudio, producing 3 binaries. I tested all 3 one by one.