MuseScore 3 cannot start with WDM-KS audio devices installed.

• Jan 8, 2019 - 08:04
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S1 - Blocker
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

MuseScore3 do not start with a soundcard or an audio interface connected. MuseScore3 can only start with a -s command line option, or with PortAudio disabled in preferences.
MuseScore2 works fine.

I have pulled and built gc73b148d1 from the repository and the issue remains existence. I got a crash log with an assertion failure:

Assertion failed!

Program: C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\build.debug\mscore\MuseScore3.exe
File: src/hostapi/wdmks/pa_win_wdmks.c, Line 1061

Expression: FALSE

Searched over the internet I found that others also reported the assertion failure in other projects using PortAudio.
This has been reported several times in the forum and the issue tracker, all labeled with "needs info" since no one has found the exact problem causing the crash on start previously.
Please at least provide a workaround to temporarily disable WDM-KS support?

Comments

• Jan 8, 2019 - 10:43
Regression No ⇒ Yes
Workaround No ⇒ Yes
Priority ⇒ P0 - Critical

Using -s is a workaround, as is using MuseScore 2, neither is a good one though...
Unfortunatly for PortAudio we're just using a DLL, not their source code to build it outselves, so a fix for this most probably needs to come from the folks at PortAudio/PulseAudio (?). Unless they already provide an option to disable WDM-KS support. Investigation needed

Reply

• Jan 8, 2019 - 11:30

Currently, I am working with MuseScore3 and my audio interface with a workaround. I unplug the audio interface before opening MuseScore, then replug it after MuseScore finished the initialization. This bypassed the PortAudio initialization issue. To use the audio interface as the playback device, I set MIDI output of MuseScore preference to send playback via loopMIDI to an external VSTi. This is a little bit confusing but works perfectly for me.

Reply

• Jan 8, 2019 - 11:46

@dilon2001: Won't help, as that explicitly states to have WDM-KS enabled, we need it disabled as I understand
@Aean: did you (re)build the portaudio.lib (using dll2lib.bat)? MSVC seems to need that (MinGW does not).

In general: the portaudio.dll we use is antediluvian, from 2009 or even older (EDIT: this is the 32bit version) ... got copied accross to the dependencies since ages, never refreshed apparently. the once from the link above are at least 4 years younger, which still is way behind where PortAudio is now, their latest stable is from 2016, latest devel from today. But source only, can't find binaries

Reply

• Jan 8, 2019 - 11:56

I just replaced a nightly built version, which I guess was built with MSVC. Now I tried with my personal, MinGW-built Debug version, still not working, but another assertion failure this time.

after paHostApiInitializers[4].
Debug: using PortAudio Version: PortAudio V19-devel (built May 26 2013 16:02:30) (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:99, virtual bool Ms::Portaudio::init(bool))
Debug: No device selected.  PortAudio detected 55 devices.  Will use the default device (index 5). (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:104, virtual bool Ms::Portaudio::init(bool))
Debug: Fluid: sf  not found (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\fluid\fluid.cpp:646, virtual bool FluidS::Fluid::loadSoundFonts(const QStringList&))
Debug: LibraryPath:  (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\musescore.cpp:7313, int main(int, char**))
Debug: LibraryPath:  (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\musescore.cpp:7313, int main(int, char**))
Fatal: ASSERT: "!Workspace::workspaces().empty()" in file C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\workspace.cpp, line 210 (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\workspace.cpp:210, )

I cannot attach the full log file, the button doesn't react to me.

Reply

• Jan 8, 2019 - 11:58

I believe that assert is having a different cause: not running MuseScore from the install directory, but from the build directory, so it doesn't find the (installed) workspace files

Reply

• Jan 8, 2019 - 12:24

@Aean, did you tried instead to run your compiled MuseScore from the install folder, aka clicking MuseScore.exe from the generated win32install/bin (for that, to generate the install folder, if you compiled a mingw debug build I think you need to do "a mingw32-make -f Makefile.mingw installdebug")? that's the reason of the other errors in your latest output I think)

Reply

• Jan 8, 2019 - 12:35

How are you building? QtCreator/MinGW or MSVC? In any case you'd need to follow the instructions in the developers' handbook, wich does explain that you need to a) install and b) run from there.

Reply

• Jan 8, 2019 - 12:48

It works! The issue has been solved, MuseScore has started and made sounds through my audio interface. So you guys just need to replace the library linked against with that version provided by @dilon2001. Thanks for your assistance @dilon2001 and @Jojo-Schmitz!

Reply

• Jan 8, 2019 - 12:53

Glad it worked but, please, could you provide us again with the debug output at the start of the MuseScore succesfull run, telling the portaudio version? (as you did above, "Debug: using PortAudio Version: PortAudio V19-devel (built May 26 2013 16:02:30) (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:99, virtual bool Ms::Portaudio::init(bool))
Debug: No device selected. PortAudio detected 55 devices. Will use the default device (index 5). ")

Reply

• Jan 8, 2019 - 12:57

Of course!

Debug: using PortAudio Version: PortAudio V19-devel (built May 26 2013 16:03:11) (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:99, virtual bool Ms::Portaudio::init(bool))
Debug: No device selected.  PortAudio detected 55 devices.  Will use the default device (index 5). (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:104, virtual bool Ms::Portaudio::init(bool))
Attachment Size
log.txt 41.51 KB

Reply

• Jan 8, 2019 - 13:14

Wait, I made it printed out by unplugging my audio interface...

Debug: using PortAudio Version: PortAudio V19.6.0-devel, revision 396fe4b6699ae929d3a685b3ef8a7e97396139a4 (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:99, virtual bool Ms::Portaudio::init(bool))
Debug: No device selected.  PortAudio detected 17 devices.  Will use the default device (index 3). (C:\Users\asus\Desktop\MuseScoreNightly\git\MuseScore\mscore\pa.cpp:104, virtual bool Ms::Portaudio::init(bool))
Attachment Size
log_unplugged.txt 10.53 KB

Reply

• Jan 8, 2019 - 13:21

Cool, got it, thanks!

I think then the developers would be so glad to take a look (check when was integrated as a dependency, etc.) over this PortAudio V19.6.0-devel, revision 396fe4b6699ae929d3a685b3ef8a7e97396139a4 , as it seems to have problems.

Reply

• Jan 8, 2019 - 13:57

To try to sort this out:
the portaudio was updated when the build environment switched to MSVC for 64bit Windows.
The automated build started to use the dlls from: https://github.com/spatialaudio/portaudio-binaries which should be based on what in http://portaudio.com/download.html is called "the most current and stable release from the Git repository on October 30, 2016, git commit 396fe4b6699ae929d3a685b3ef8a7e97396139a4".
During lunch time today I tried to build this very same portaudio git commit with MSVC (while in that github repo they were cross-compiling with mxe). Attached you can find the resulting dll (64bit).
@ Aean : can you please try this dll and see if it works for your WDM-KS device?

Attachment Size
portaudiodll.zip 256.18 KB

Reply

• Jan 8, 2019 - 13:59

Jojo, the user tried with the PortAudio embebbed in the nightly (and I suppose too, it's the same in the 3.0 final released recently) and it crashed with an assert.

Then he tried with another different portaudio version, the one in the link I gave above. Then it worked.

Exactly, what do you mean? I'm not an expert regarding SVN versions/builds/etc., but I'm just getting the suspect that the current portaudio as distributed with 3.0 has its problems regarding certain devices - and a logical thing (I think) would be to research since when it was integrated on the MuseScore 3.0 (nightlies , etc.). It's clear that starting the release of MuseScore 3.0 , there are a much more ample user base who can reveal more crearly obscure problems in their audio devices.

edit: well, @ABL clarified above, thanks!

Reply

• Jan 8, 2019 - 14:06

@ABL: Ah! Good to know. Do you have a 32bit version of it too please?
OTH why didn't MuseScore 3.0 not work out of-the-box for @Aean? It should have had that DLL already, shouldn't it?

Reply

• Jan 8, 2019 - 14:11

DLL provided by @ABL have a file size of 598KB, DLLs shipped with nightly builds, shipped with official stable version and from compilation guide of developer handbook are 359KB. DLL provided by @dilon2001 is 187KB. These are three different versions.

Reply

• Jan 8, 2019 - 14:26

OK, now I'm completly lost. Which version are we currently using, whioch are broken, which work and what should we be using?
And need it for 32bit too, preps for being able to provide a 32bit MuseScore as soon as AppVeyor supports Qt 5.12...

Reply

• Jan 8, 2019 - 14:37

Thanks Aean

...then this bug, it seems a MSVC/Visual Studio build issue-only, then, @ABL?? (bug caused by the cross recompiled dll binary from the external repository, the spatialaudio one) if so I'm so glad this just reduces the problem to a simple replace of dll in the the 3.0 (and nightly) downloads

Reply

• Jan 8, 2019 - 14:42

OK, I see. Would still be nice to also get a working 32bit version (although I don't even know whether the existing one is broken in the same way or just much older, it is from 19th March 2009, at most, maybe even older)

Reply

• Jan 8, 2019 - 17:19

Yes, I suspect as well that it could be a problem of the cross-compilation (MinGW compilation).
Here are the x64 and x86 libraries, with correct import libraries (the one in the previous attachment was not working). I tried to compile the x86 with backward compatibility for Windows Xp, but I could not test this 32bit library.
The 64bit library works in my environment: @ Aean can you please try this one as well? (I had to recompile it and change a couple of parameters, but I hope it will still work as the previous one)

Attachment Size
addition_to_dependencies.zip 470.45 KB

Reply

• Jan 9, 2019 - 08:42

@ Aean : thanks a lot for your help.
I quickly tried the 32bit dll by substituting the dll in MuseScore 2.3 installation "bin" folder and in my system it worked. So I assume it should work.
(MuseScore 2.3 was built with 32bit MinGW. Trying to do the same trick in a MSVC compiled MuseScore 3.0.1-dev apparently leads to an error message complaining that the dll is not the one it linked against. One more reason why I prefer MinGW instead of MSVC)

Now we simply have to wait for these dlls (and maybe also the updated header) to substitute the ones present in the current dependencies zip bundle, and the following Nightly build should work also for wdm/ks devices.

Once again, thank you very much for your help and commitment :-)

Reply

• Jan 9, 2019 - 08:44
Status active ⇒ PR created

Changing the status because we have the patch, even if an official github PR cannot be created (the dependencies bundle is not hosted on github).

Reply

• Jan 9, 2019 - 08:52
Status PR created ⇒ active

@Aean: Qt 5.12 does provide means to build a 32bit version, but only with MSVC (the official builds use MSVC, MinGW is not really supported anymore, even if it still works). For MinGW indeed it is 64bit only in 5.12 and 32bit only in 5.9

Reply

• Jan 9, 2019 - 22:22
Regression Yes ⇒ No
Severity S1 - Blocker ⇒ S3 - Major
Workaround Yes ⇒ No

Hello, I tried to use the portaudio.dll you provided and I placed it under Musecore 3/bin, replacing the old one with it. But this resulted in an error which i attached below and MuseScore doesn't start at all.

Attachment Size
Capture.PNG 109.56 KB

Reply

• Jan 10, 2019 - 08:46
Regression No ⇒ Yes
Severity S3 - Major ⇒ S1 - Blocker
Workaround No ⇒ Yes

Yes, that lib needs to get properly linked into MuseScore, at least for MSVC builds, see further up

It still is a regression and a blocker, and the workaround still is to use -s or using MuseScore 2

Reply

• Jan 17, 2019 - 16:20

Forgive me, but some of this is a tad over my head. I'm having the same issue on two of my Windows 10 Machines, but are fully updated and running v3.0.1. How do I fix this?

Reply

Fix version
3.0.1