Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JACK 1.9.16 doesn't work on Win 10 #654

Open
halbius opened this issue Oct 20, 2020 · 35 comments
Open

JACK 1.9.16 doesn't work on Win 10 #654

halbius opened this issue Oct 20, 2020 · 35 comments

Comments

@halbius
Copy link

halbius commented Oct 20, 2020

Hi,

I just installed the latest version 1.9.16 using a 64 bit binary (Win10 Pro, 64 bit). But JACK doesn't start. Wether I start it from command line or via QJackctrl, it freezes.
From former installations I remebered these instructions: https://jackaudio.org/faq/jack_on_windows.html
But I couldn't find any JackRouter.dll, so I think it's kind of obsolete. After all I unregistered the former JackRouter.dll, but the only effect is that audio applications don't find any Jack anymore.

Can anybody help me with this? Would be great to get it running again...

If you need more information, please let me know.

Thanks a lot!
@falkTX
Copy link
Member

falkTX commented Oct 20, 2020

Did you uninstall the previous jack version before installing the new one?
There might have been some conflicts.

And yes, applications that do not speak JACK natively will not be able to talk to JACK anymore.

@halbius
Copy link
Author

halbius commented Oct 23, 2020 via email

@falkTX
Copy link
Member

falkTX commented Oct 23, 2020

Wow, that's really bad news as most of my applications are not natively speaking JACK...

The list is growing slowly.

Ardour / Mixbux
Bitwig
Carla Plugin Host
LMMS (in nightly builds)
Radium

Maybe we should make a list of those.

In any case, yes, jack-router is not supported anymore.
Were you able to get JACK to start via QjackCtl yet?

@johne53
Copy link

johne53 commented Oct 27, 2020

Robin Gareus (Mixbus developer) contacted me yesterday and asked if I'd try the latest version of Jack (v1.9.16). Several years ago, Mixbus (on Windows) lost its ability to launch Jack but this is now fixed. I removed my old Jack (v1.9.11) and downloaded 1.9.16 - and sure enough, the startup problem is solved now.

BUT... v1.9.16's performance seems very poor compared to 1.9.11. MB uses a 'DSP reading' to display performance and readings now are up by around 70% after updating Jack (this is on Windows 7 BTW). For example a session which previously showed 30% DSP will now be showing over 50%.

I believe that Stephane's no longer involved with Jack but FWIW, this was also a problem back in Stephane's day. Occasional builds would suddenly produce poor performance - but each time I flagged it up, he was always able to fix it somehow (unfortunately I don't know how...)

I know that's not much help but just wanted to flag it up again.

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

Can also be a question of the optimizations used.
For the moment you can see at https://github.com/DISTRHO/PawPaw/blob/3a5a8c72d03843694dbc6c728d8ecabbb2051c59/setup/env.sh#L46
This is -O2 -mtune=generic -msse -msse2 -mfpmath=sse -ffast-math. The -mtune parameter could be "bumped" to support higher CPU optimizations, but with less supported CPUs.

@sletz do you recall what flags were used to build jack on windows before?

@sletz
Copy link
Member

sletz commented Oct 27, 2020

Nope...

@johne53
Copy link

johne53 commented Oct 27, 2020

With my Mixbus transport rolling (and the same session) Jack v1.9.11 never gets above 0% in Task Manager - whereas v1.9.16 shows between 1% and 3%. Another possible significance is that both jackd.exe and jack_portaudio.dll are both A LOT smaller than they used to be:-

64-bit jackd.exe (from yesterday) is showing here as 914,944 bytes - the previous version was 5,464,435 bytes (also 64-bit, I think)
jack_portaudio.dll from yesterday is showing 1,083,392 bytes - the previous version was 5,488,942 bytes

IIRC Stephane used to build with a compiler called something like TDM-GCC so has the compiler changed now? Maybe that's the problem?

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

the entire build chain has changed. used to be MSVC, and now uses mingw

@johne53
Copy link

johne53 commented Oct 27, 2020

Yeah I know - I'm the one who built it with MSVC !!

BTW - to answer kmatheussen, here's what Task Manager shows me for the same session with different backends:-

Dummy backend - Mixbus CPU usage = 24%
Jack v1.9.11 - Mixbus CPU usage = 46%
Jack v1.9.16 - Mixbus CPU usage = 54%

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

oh haha, sorry, I was not aware.

that Dummy backend is with 1.9.11 or 1.9.16?

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

@falkTX which version of pulseaudio is included with 1.9.16?

you mean portaudio? then it is the debian re-packaged 19.6.0.
fetched from http://deb.debian.org/debian/pool/main/p/portaudio19

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

From what I know that matches the http://portaudio.com/archives/pa_stable_v190600_20161030.tgz tarball, it is just repackaged in a more sane version scheme and filename.

@johne53
Copy link

johne53 commented Oct 27, 2020

AFAIK the dummy backend doesn't launch Jack at all. I just tried again (though this time on Windows 8, rather than Windows 7) and got some very curious results:-

Dummy backend - Mixbus CPU usage = 45%
Jack v1.9.11 - Mixbus CPU usage = 47%
Jack v1.9.16 - Mixbus CPU usage = 55%

@kmatheussen I've heard of wasapi but I'm not quite sure what it is. AFAIK though, I don't use it. With Jack I'm using ASIO4ALL here.

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@johne53
Copy link

johne53 commented Oct 27, 2020

Ah, I get it - I was using Mixbus's dummy backend (I hadn't realised that Jack itself offers a dummy backend). Here's what I found:-

Jack v1.9.11 with Jack's dummy backend - Mixbus CPU usage varies wildly between 32% and 48%
Jack v1.9.16 with Jack's dummy backend - Mixbus CPU usage is steady at around 54%

Also - by "not launching Jack" I meant that Mixbus and Ardour weren't able to start Jack at all on Windows (if you selected Jack, they both just silently reverted to the ardour portaudio driver)

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@johne53
Copy link

johne53 commented Oct 27, 2020

Mixbus itself already has EQ and compression plugins on every channel. I could decrease my audio buffer size (which would take me closer to glitching) but I'm not quite sure what that'll prove

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@johne53
Copy link

johne53 commented Oct 27, 2020

But surely we already know that? Mixbus reports a higher DSP figure with v1.9.16 and Task Manager reports Mixbus having a higher CPU usage - and Jack having a hgher CPU usage too.

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

Maybe the -X winmme causes more DSP load by default?

@johne53 can you try removing that from the jack start command with 1.9.16?
It is enabled by default because it is just too useful to leave out, and not obvious how to enable if that was not the initial state.

@kmatheussen
Copy link
Contributor

kmatheussen commented Oct 27, 2020 via email

@johne53
Copy link

johne53 commented Oct 27, 2020

Hmmm... this has gotten even stranger. With v1.9.16, Mixbus won't launch any more if I've already started Jack from a command line. If I shut down Jack using Task Manager, Mixbus immediately launches. At first I figured it must be an issue with Mixbus - but lo & behold if I go back to v1.9.11 the problem disappears.

I'll have to leave this for tonight guys as it's getting quite late here - but thanks for all your help today!

@johne53
Copy link

johne53 commented Oct 27, 2020 •
edited
Loading

Aaaargh!!! A light bulb just went on !!

We established earlier that Jack has moved to a different compiler now - but here of course, I'm still using the libjack DLL that corresponded to v1.9.11 (maybe Robin is too). We should really upgrade to use the newer libjack that corresponds to 1.9.16.

Can someone please let me know where I can obtain the newer libjack (lib and dll) as well as the corresponding header files? If I can find some time tomorrow I'll try building against them and see if that fixes things.

@falkTX
Copy link
Member

falkTX commented Oct 27, 2020

We established earlier that Jack has moved to a different compiler now - but here of course, I'm still using the libjack DLL that corresponded to v1.9.11 (maybe Robin is too). We should really upgrade to use the newer libjack that corresponds to 1.9.16.

I doubt that is something that is happening.
when you install jack, it installs the DLLs into the windows directory, making JACK available globally.
Ardour and Mixbus do not ship with any JACK DLLs, it opens the one in the windows dir, if present.

@johne53
Copy link

johne53 commented Oct 28, 2020

Thanks Filipe - my reasoning was that I hadn't rebuilt Mixbus after installing v1.9.16 so Mixbus itself would still be using the old header files and link lib from v1.9.11. I just wondered if there might be some incompatibility between them (which there is...)

This morning I rebuilt, making sure I built against your newer header files and link lib. The good news is that Mixbus will launch now if Jack is already running - however, its DSP figure is actually worse than yesterday :-(

A session which (yesterday) gave me 28% DSP is now showing 56%. I launched the ASIO4ALL control panel and realised there's a problem now with the buffer size. If I select a size of 2048 samples (within Mixbus) ASISO4ALL actually gets set to 512.

I'll need to dig a bit deeper into this but unfortunately I'm having some dental work done this week so my time will be a bit patchy. One thing did occur to me though... do you happen to know what alignment value gets used now for structs within Jack? Most compilers default to 8-byte alignment but in the very early days, we realised that not all compilers agree about what constitutes "8 bytes". So we needed to use some macros to reset it to 1-byte alignment. If it isn't set to 1-byte, Jack will give all manner of weird problems if the server & client were built using different compilers.

From memory, the macros were called PRE_PACKED_STRUCTURE and POST_PACKED_STRUCTURE. Do you know if they're still in use these days (i.e. by your current compiler?)

@johne53
Copy link

johne53 commented Oct 28, 2020 •
edited
Loading

johne53 wrote:

If I select a size of 2048 samples (within Mixbus) ASISO4ALL actually gets set to 512.

A bit more good news... I just realsed that no matter what settings I choose in Mixbus, it always seems to start Jack now at 44100 Hz and 512 buffer size. Yesterday I'd been intending to start with a buffer size of 2048 samples - so I wondered if that might explain the increase in DSP usage.

Knowing I can now start Jack and then launch Mixbus later, I tested this by launching Jack from a command line using this command:-

"C:\Program Files\JACK2\jackd.exe" -S -dportaudio -r44100 -p2048 -P "ASIO::ASIO4ALL v2" -C "ASIO::ASIO4ALL v2"

I then launched Mixbus and the DSP reading is now much closer to what I'd usually expect.. So I guess the Ardour/Mixbus devs need to figure out if something's wrong at their end.

At Jack's end though, there's a problem with v1.9.16 which doesn't seem to work if the client app got created with some earlier version (or maybe it'll work for some compilers but not others). This has a;ways worked in the past AFAIK.

[Edit...] Apologies for the confusion but it looks like I was wrong yesterday about the improved performance. My session from yesterday had previously shown 10% DSP with v1.9.11 - which increased to 17% with 1.9.16. but I must have misread the figure yesterday and thought it said 11%. It's definitely showing 17% this morning - sorry... :-(

And I've now had an opportunity to try Jack without the -S parameter and I also tried adding -X winmme but neither of them improves the performance AFAICT.

@falkTX
Copy link
Member

falkTX commented Oct 28, 2020

That is some good news, thanks for all the investigation

At Jack's end though, there's a problem with v1.9.16 which doesn't seem to work if the client app got created with some earlier version (or maybe it'll work for some compilers but not others). This has a;ways worked in the past AFAIK.

I do not know about this, more details needed. Likely best in a separate ticket though.
This one is side-tracked enough haha

@x42
Copy link
Member

x42 commented Oct 28, 2020

At Jack's end though, there's a problem with v1.9.16 which doesn't seem to work if the client app got created with some earlier version (or maybe it'll work for some compilers but not others). This has a;ways worked in the past AFAIK.

That's why libjack.dll was not compiled with mingw in the past. It cannot produce compatible __stdcall ABI.
MSVC can link by function-name, instead of using ordinals, mingw does not offer this. (Perhaps recent dlltool can provide a map .def/.lib, it's been a few years since I've last checked.)

@falkTX
Copy link
Member

falkTX commented Oct 28, 2020

Perhaps recent dlltool can provide a map .def/.lib, it's been a few years since I've last checked

I think llvm-dlltool can do this, but I did not check throughly.
for now I only used it to create the def and lib files from the mingw dll, without modifying its output.
the current def file is like:

EXPORTS
    jack_acquire_real_time_scheduling @1
    jack_activate @2
    jack_client_close @3
    jack_client_create_thread @4
    jack_client_get_uuid @5

@johne53
Copy link

johne53 commented Oct 29, 2020

johne53 wrote:

One thing did occur to me though... do you happen to know what alignment value gets used now for structs within Jack? Most compilers default to 8-byte alignment but in the very early days, we realised that not all compilers agree about what constitutes "8 bytes". So we needed to use some macros to reset it to 1-byte alignment. If it isn't set to 1-byte, Jack will give all manner of weird problems if the server & client were built using different compilers.

From memory, the macros were called PRE_PACKED_STRUCTURE and POST_PACKED_STRUCTURE. Do you know if they're still in use these days (i.e. by your current compiler?)

I mentioned yesterday that Jack v1.9.16 doesn't work now if the client got built with some earlier version (I'm pretty sure this always worked in the past...)

After some tests this morning with Ardour, it's the call to 'jack_client_open()' which fails (it hangs). However - if I pre-start Jack from a command line, I see this output when the hang occurs - which does seem to indicate some kind of size issue:-

  CheckSize error size = 81 Size() = 85
  CheckRead error

'jack_client_open()' accepts a parameter of 'jack_status_t' but it's a simple enumeration so I doubt if that'll be the problem. Maybe that'll give someone a clue though...

@x42
Copy link
Member

x42 commented Oct 29, 2020

@johne53 I suspect this is due symbol mismatch. lookup by (ordinal) number, instead of by name. Perhaps you use different .lib or .dll when linking. -- For Ardour builds we use https://github.com/x42/weakjack#weak-jack and resolve symbols at runtime to work around this.

@johne53
Copy link

johne53 commented Oct 31, 2020 •
edited
Loading

johne53 wrote:

I just realsed that no matter what settings I choose in Mixbus, it always seems to start Jack now at 44100 Hz and 512 buffer size.

I just found the reason for this (it's a Jack installer problem). It's quite a simple explanation so should I post it here or start a new thread?

[Edit...] New thread started:- #660 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@x42 @kmatheussen @falkTX @sletz @johne53 @halbius