Playback Audio Devices missing in develop (no sound on Windows)

[jonoomph]

When I compare OpenShot 2.5.1 and OpenShot 2.6.0 (release candidate) on Windows, I have noticed what appears to be a regression in libopenshot-audio, with regards to missing audio devices. I am currently getting no audio playback on Windows, and this is a release blocking issue for 2.6.0. I'm going to do some testing today, and see if I can figure out when this issue was introduced, but my guess is this was due to either an upgrade of our Windows build server, or one of our JUCE upgrades... and perhaps some dependency missing, or packaging issue/missed file. Not really sure yet.

OpenShot 2.5.1 Audio Devices: Sound plays perfectly on Windows 10

OpenShot 2.6.0 Error: No sound works on this version

OpenShot 2.6.0 Audio Devices: Notice there are a few missing when compared to 2.5.1

[jonoomph]

@ferdnyc I am hoping you might have some theories. 🙏 Thanks!

[ferdnyc]

Hmmmmmm. So it's not seeing the Windows Audio devices anymore? Interesting. I'll look at a few things.

This may actually be indirectly related to something I just posted to the JUCE forums yesterday, as well. https://forum.juce.com/t/audiodevicemanager-gets-tripped-up-by-empty-but-available-device-types/47501

Though in this case it's actually the opposite problem. (I did manage to fix openshot-audio-demo to work on Windows from the MinGW console, though. #132 is that fix. But it wouldn't affect OpenShot.)

[ferdnyc]

@jonoomph

OK, there's definitely something up with the build. I'm just not sure what/why yet.

I just built libopenshot-audio on the builder in an MinGW64 shell. The result (which is in C:/msys64/home/Administrator/libopenshot-audio/build_x64/) shows DLL dependencies like you'd expect:

# ldd build_x64/libopenshot-audio.dll
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77720000)
        kernel32.dll => /c/Windows/system32/kernel32.dll (0x77500000)
        KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefd3f0000)
        ADVAPI32.dll => /c/Windows/system32/ADVAPI32.dll (0x7feff8c0000)
        msvcrt.dll => /c/Windows/system32/msvcrt.dll (0x7feff720000)
        sechost.dll => /c/Windows/SYSTEM32/sechost.dll (0x7fefe4f0000)
        RPCRT4.dll => /c/Windows/system32/RPCRT4.dll (0x7fefd630000)
        ole32.dll => /c/Windows/system32/ole32.dll (0x7fefe930000)
        GDI32.dll => /c/Windows/system32/GDI32.dll (0x7feff9a0000)
        USER32.dll => /c/Windows/system32/USER32.dll (0x77620000)
        LPK.dll => /c/Windows/system32/LPK.dll (0x7feff710000)
        USP10.dll => /c/Windows/system32/USP10.dll (0x7fefeb30000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x7fef53b0000)
        SHELL32.dll => /c/Windows/system32/SHELL32.dll (0x7fefd760000)
        SHLWAPI.dll => /c/Windows/system32/SHLWAPI.dll (0x7fefe8b0000)
        VERSION.dll => /c/Windows/system32/VERSION.dll (0x7fefc340000)
        WININET.dll => /c/Windows/system32/WININET.dll (0x7feff260000)
        api-ms-win-downlevel-user32-l1-1-0.dll => /c/Windows/system32/api-ms-win-downlevel-user32-l1-1-0.dll (0x7fefd470000)
        api-ms-win-downlevel-shlwapi-l1-1-0.dll => /c/Windows/system32/api-ms-win-downlevel-shlwapi-l1-1-0.dll (0x7fefd460000)
        api-ms-win-downlevel-version-l1-1-0.dll => /c/Windows/system32/api-ms-win-downlevel-version-l1-1-0.dll (0x7fefd620000)
        api-ms-win-downlevel-normaliz-l1-1-0.dll => /c/Windows/system32/api-ms-win-downlevel-normaliz-l1-1-0.dll (0x7fefd2e0000)
        normaliz.DLL => /c/Windows/system32/normaliz.DLL (0x778d0000)
        iertutil.dll => /c/Windows/system32/iertutil.dll (0x7fefef30000)
        api-ms-win-downlevel-advapi32-l1-1-0.dll => /c/Windows/system32/api-ms-win-downlevel-advapi32-l1-1-0.dll (0x7fefd4a0000)
        USERENV.dll => /c/Windows/system32/USERENV.dll (0x7fefd480000)
        profapi.dll => /c/Windows/system32/profapi.dll (0x7fefd280000)
        WINMM.dll => /c/Windows/system32/WINMM.dll (0x7fefa2e0000)
        WS2_32.dll => /c/Windows/system32/WS2_32.dll (0x7feff7c0000)
        NSI.dll => /c/Windows/system32/NSI.dll (0x7feff8b0000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x7fef4060000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x7feed670000)
        zlib1.dll => /mingw64/bin/zlib1.dll (0x7fef08d0000)
        IMM32.DLL => /c/Windows/system32/IMM32.DLL (0x7fefe510000)
        MSCTF.dll => /c/Windows/system32/MSCTF.dll (0x7fefec00000)

But the one the builder generated is craaazy. It even references itself:

# ldd /C/Users/Administrator/builds/7546b651/0/OpenShot/libopenshot-audio/build/libopenshot-audio.dll
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77720000)
        kernel32.dll => /c/Windows/system32/kernel32.dll (0x77500000)
        KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefd3f0000)
        libopenshot-audio.dll => /c/Users/Administrator/builds/7546b651/0/OpenShot/libopenshot-audio/build/libopenshot-audio.dll (0x73ec0000)

Now, the trick is to figure out why.

[jonoomph]

I'm still hunting for the commit where this behavior changes... It's a long time ago for sure. I'll keep you posted, as I'm hoping this info will be valuable.

[ferdnyc]

@jonoomph Is it? I have the 2.5.1.7703 build (which would be from July 3) installed on Windows, and I can see all devices:

[ferdnyc]

Ohhhh, but that was still bundled with the old libopenshot-audio.dll from (MinGW) /usr/local/bin/, I bet.

[ferdnyc]

Interesting. With the latest 2.6.0 RC installed, my list is somewhat different, but still includes Windows Audio devices:

[jonoomph]

Windows Audio Tests
@ferdnyc I ran through a bunch of installers, trying to find the moment everything breaks on my Windows 10 laptop. I think I found it: #88.

openshot-qt repo

Mar 31, 2021 (7045) - Fail
Jan 29, 2021 (6545) - Fail
Nov 16, 2020 (6020) - Fail
Oct 16, 2020 (5656) - Fail
Sep 27, 2020 (5581) - Fail
Sep 12, 2020 (5531) - Fail
Sep 11, 2020 (5522) - Fail
Sep 11, 2020 (5519) - Fail [8:08am]
******** FAILURE HAPPENS HERE *********
Sep 11, 2020 (5514) - Works [4:38am]
Sep 10, 2020 (5504) - Works
Aug 21, 2020 (5391) - Works
Aug 17, 2020 (5333) - Works
July 23, 2020 (5126) - Works

libopenshot-audio repo

• Sep 11, 2020 (5517) - Upgrade JUCE to 5.4.7 (Upgrade JUCE to 5.4.7 #88) [7:10am]
  • http://gitlab.openshot.org/OpenShot/libopenshot-audio/commit/12ddb3df0012552eff05a092e7f81cddd0884933
• Aug 17, 2020 (5316) - Merge OpenShot/new-webengine-support

libopenshot repo

• Sep 11, 2020 (5518) - Merge pull request #558 from OpenShot/juce-547 [7:13am]
  • http://gitlab.openshot.org/OpenShot/libopenshot/commit/ac8966ad7d630dba45424b7624d5a9a0b1f06278

[jonoomph]

JUCE_DONT_AUTOLINK_TO_WIN32_LIBRARIES 1 🤔 ???

[ferdnyc]

Red herring, that's only for Visual Studio.

[ferdnyc]

(It appears there because we used to be setting it in the CMakeList.txt — I have no idea why — so I moved it to where it's supposed to be set. Still no point in setting it, but we do.)

[ferdnyc]

I think the issue is that we're going to have to both save and set the AudioDeviceType along with the name. Their fallback stuff for type selection is... fucked up. If you set a preferredDefaultDeviceName in initialise() (which we do), initialiseDefault() will scan all of the device types for a matching name, and if it finds one it will store it in setup.outputDeviceName. But then when setAudioDeviceSetup() is called later, it only tries to find that device name in the getCurrentAudioDeviceTypeObject(), and if the type where the name was found isn't the current device type, that leads to those "No device found" errors.

[ferdnyc]

(This is also why my idea to try setting "*" as the preferred default device name — which should in theory match any device — doesn't work as expected. If the current type isn't correct for the device name matched, it'll still fail on selection. The only right way to make this work, it seems, is to call findType("", PLAYBACK_AUDIO_DEVICE_NAME) to get the correct type, and then setCurrentAudioDeviceType() with that type, before initializing.)

[ferdnyc]

So I'm thinking this is a libopenshot fix, ultimately. The change in the JUCE version altered the API, but the way we're using it has to change there. (In Qt/AudioPlaybackThread.cpp, specifically.)

[jonoomph]

@ferdnyc Are you currently remoted into the Windows build server? http://gitlab.openshot.org/OpenShot/openshot-qt/-/jobs/26935. No worries if you are.. .just curious why the builder is failing due to Power Shell. 😉

[ferdnyc]

@jonoomph I am, yeah. I can drop out, though, I'm done there for now and can test what I need to on my local Windows box. ...Done, I'm off.

[ferdnyc]

UGH. findType() is private, WTF!?

[jonoomph]

You are correct about JUCE_DONT_AUTOLINK_TO_WIN32_LIBRARIES. Useless and changed nothing. At least I can scratch this off the list now, lol. I agree with your ideas about a libopenshot change to how we initialise() things.

[ferdnyc]

I updated my post in the JUCE forums with the details about devicetype-switching being kind of broken, not that anyone's even responded to the original post yet.

[ferdnyc]

I think my findings about the linking being weird were incorrect. dumpbin.exe (from Visual Studio tools) shows the correct dependencies, not sure why CMake's ldd doesn't. Maybe something to do with the import library (libopenshot-audio.dll.a) not being in the same directory anymore.

[jonoomph]

#define JUCE_WASAPI_EXCLUSIVE 0 🤔 ??? Just grasping at any difference between the previous JUCE version.

[ferdnyc]

@jonoomph

So, I think I'm actually close on this. The audio-devices branch in libopenshot resurrects some old code I had laying around, and adds type switching. There's supposed to be a corresponding openshot-qt branch, but I've been fighting with preferences.py trying to store the data, and handle old prefs with no type saved, etc.

And right now I'm headed to dinner with a friend from out of town, so it'll be a bunch of hours before I get back to it.

[ferdnyc]

#define JUCE_WASAPI_EXCLUSIVE 0 🤔 ??? Just grasping at any difference between the previous JUCE version.

Another red herring. They actually configure WASAPI devices BOTH ways by default. That flag is actually gone in JUCE 6, it's become a 3-way "mode" enumeration. (There's non-exclusive mode, exclusive mode, and... another variation of exclusive mode, IIRC.)

I'm really not sure WHAT changed between the two versions, TBH. Meanwhile, after I submitted #132 I discovered WHY the demo app showed no WASAPI devices. Running it through the debugger, I noticed some debug messages about COM not being initialized.

Turns out, the Win Audio device discovery uses COM. Including the combaseapi.h header -- or something like that -- and putting a call to CoInitialize() at the start of the program fixed discovery. But the WASAPI outputs still don't WORK, they just showed up. I only got sound out of the DirectSound ones. Most likely because the test app still isn't a "real" Windows app.

That shouldn't apply to OpenShot, which IS a real Windows app. Its startup stuff should handle that initialization automatically. (But then again, CoInitialize() needs to be called once per THREAD...)

[stale]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 90 days
• No one is assigned to this issue

We'd like to ask you to help us out and determine whether this issue should be reopened.

• If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention.
• If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks again for your help!