search

OpenShot / libopenshot-audio

OpenShot Audio Library (libopenshot-audio) is a free, open-source project that enables high-quality editing and playback of audio, and is based on the amazing JUCE library.
http://www.openshot.org
GNU General Public License v3.0
254 stars 101 forks source link

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

Closed jonoomph closed 2 years ago

jonoomph commented 3 years ago

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 Windows-Audio-Devices-2-5-1-preferences

OpenShot 2.6.0 Error: No sound works on this version Windows-Audio-Devices-2-6-0-launch-error

OpenShot 2.6.0 Audio Devices: Notice there are a few missing when compared to 2.5.1 Windows-Audio-Devices-2-6-0-preferences

jonoomph commented 3 years ago

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

ferdnyc commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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:

Screenshot from 2021-08-23 21-49-44

ferdnyc commented 3 years ago

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

ferdnyc commented 3 years ago

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

image

jonoomph commented 3 years ago

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

libopenshot repo

jonoomph commented 3 years ago

JUCE_DONT_AUTOLINK_TO_WIN32_LIBRARIES 1 🤔 ???

ferdnyc commented 3 years ago

Red herring, that's only for Visual Studio.

ferdnyc commented 3 years ago

(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 commented 3 years ago

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 commented 3 years ago

(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 commented 3 years ago

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 commented 3 years ago

@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. :wink:

ferdnyc commented 3 years ago

@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 commented 3 years ago

UGH. findType() is private, WTF!?

jonoomph commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ferdnyc commented 3 years ago

@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 commented 3 years ago

#define JUCE_WASAPI_EXCLUSIVE 0 :thinking: ??? 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[bot] commented 3 years ago

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:

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

Thanks again for your help!