Thanks. I have already rebuilt jack with --profiling option and started it, but seems nothing changed. No a JackEngineProfiling.log file apeared after starting jackd. How can I receive the profiling information from the running server and make the? -- Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

To be honest I don't know. It was years ago that I used this, maybe it's another part of the code that is broken nowdays..? JACK2 isn't really maintained anymore, but hopefully that will change in the future. On Sun, 8 Jul 2018 00:13:09 -0700 (MST) oleg68 <osamarin68(a)gmail.com> wrote: -- Joakim

On Sun, July 8, 2018 1:57 pm, Joakim Hernberg wrote: Many months back falkTX took on maintenance for both jackd v1 and jackd v2 code, so jack2 is maintained to the same extent as jack1. FalkTX previously posted plans for 2018, primarily clean up tasks like getting shared headers (i.e. shared between jack 1 and jack 2) fully working, porting the zita-ajbridge based clients from jack v1 to jack v2, I think also porting in a2jmidid internal client to jack v2. I have no idea how much progress has been made on those; I'm sure clean patches would probably be accepted. -- Chris Caudle

profiling activated" in the standard output. Hi, I'd like to report that out of curiosity, I just built and installed jack2-1.9.12, here on openSUSE Tumbleweed, with the profiling enabled with --profile configure flag. Here's what I get: ==================================== /usr/local/bin/jackd -P30 -dalsa -r44100 -p256 -n2 -Xseq -D -Chw:M1010LT,0 '-Phw:M1010LT,0' jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2016 Grame. Copyright 2016-2017 Filipe Coelho. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK server starting in realtime mode with priority 30 self-connect-mode is "Don't restrict self connect requests" Engine profiling activated, beware 197 MBytes are needed to record profiling points... creating alsa driver ... hw:M1010LT,0 |hw:M1010LT,0|256|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback port created: Midi-Through:midi/playback_1 port created: Midi-Through:midi/capture_1 port created: M-Audio-Delta-1010LT:midi/playback_1 port created: M-Audio-Delta-1010LT:midi/capture_1 Jack main caught signal 15 port deleted: M-Audio-Delta-1010LT:midi/playback_1 port deleted: Midi-Through:midi/playback_1 port deleted: M-Audio-Delta-1010LT:midi/capture_1 port deleted: Midi-Through:midi/capture_1 Write server and clients timing data... JackEngineProfiling::Save cannot open JackEngineProfiling.log file JackEngineProfiling::Save cannot open Timing1.plot file JackEngineProfiling::Save cannot open Timing2.plot file JackEngineProfiling::Save cannot open Timings.html file JackEngineProfiling::Save cannot open generate_timings file *** Killed process *** ==================================== Note you must stop the server before the profiling info can be gathered and written, as shown in that .pdf link someone posted. I'm not sure if it could not write because I ungracefully killed it, or it's simply a permissions/location thing, probably the latter, I have not looked into it any further yet... Tim. The MusE sequencer project.

On Sun, Jul 8, 2018 at 9:13 AM, oleg68 <osamarin68(a)gmail.com> wrote: Maybe you have to set JACK_CLIENT_DEBUG to 1?

To put my money where my mouth is (so to speak :) I just built JACK2 1.9.12 with the --profile option. I started it with: jackd -P80 -p512 -t5000 -dalsa -dhw:DSP,0 -r44100 -p128 -n2 -Xseq On startup JACK2 reported: Engine profiling activated, beware 197 MBytes are needed to record profiling points... And on shutdown: Write server and clients timing data... The data is there and gnuplot can display it. Possible issues it seems to store the data in the current working dir. No idea where that might be if started from qjackctl or with dbus. Maybe best to start it from the command line to be sure that you know where the data ends up -- Joakim

Managed to only send this offlist, trying agian. On Tue, 10 Jul 2018 12:36:50 +0200 Stéphane Letz <letz(a)grame.fr> wrote: Indeed :) Sorry for insinuating that JACK2 was bit rotting..! Do you know if PROMISCIOUS mode is supposed to work? Last time I tried (a few years ago) I could not get it working with JACK2. -- Joakim

On 07/13/2018 04:21 PM, oleg68 wrote: Hm, no ./waf install step? Although it appears that the jackd you built is in fact the one that is running, it seems possible to me that it may be loading all of its libraries from a previous jack installation such as in /usr or /usr/local - libraries that were not built with the profiling. Try the install step which should replace those libraries. I find that it is always a good idea to run "sudo ldconfig" after playing around with jack install steps, so that the system really can find the correct libraries. That is supposed to happen automatically with most software, but I found sometimes it doesn't with jack, possibly with just one of the jack versions, I can't recall which. Tim. The MusE sequencer project.

On Sat, Jul 14, 2018 at 12:41:28AM -0700, oleg68 wrote: You need to tell "./waf configure" to install jack over the existing jack package files. On Debian systems I use --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu Your distro may use different locations, but it's easy to check. John

On 07/14/2018 04:15 AM, John Rigg wrote: I would not recommended that. Always a bad idea. It will interfere with packaging. /usr/local is the place where all user-built software should be installed. Two versions of Jack can happily coexist - one in /usr and one in /usr/local. Only one can be active at a time of course. But it is easy to switch between them. If you want to switch back to the packaged version simply uninstall your user-built version from /usr/local. Thus I mentioned "sudo ldconfig" /may/ be sometimes required (I think it may have been with jack-1) so that the system can find (switch over to) the new libraries, to be able to immediately start using the new installation. Tim.

"Chris Caudle" <chris(a)chriscaudle.org> writes: Putting /usr/local/bin first in PATH ? I do that kind of thing frequently. I don't think that bullshitting RPM is really the way to go. -- David Kastrup

On 07/14/2018 02:47 PM, Chris Caudle wrote: It should be automatic. All user-built software is usually installed in /usr/local. Most systems automatically look in /usr/local/bin FIRST before /usr/bin when you type an un-pathed program name This makes it very easy to run your own builds of software while NOT disturbing the packaging system's installed versions in any way. I routinely run my built versions of jack-1 or jack-2 installed in /usr/local, all while my distro's jack-2 package installation sits undisturbed in /usr. When I want to go back to the packaged version, I simply uninstall my built version, that MUST be done, to go back. This is how I helped debug jack-1 and jack-2 at the same time. Cheers. Tim.

On 07/14/2018 03:28 PM, Chris Caudle wrote: Ah, terribly sorry, yes, some distros don't include that path. Others do. And they /should/. Assuming that is done, when you build and install software the installer usually is supposed to automatically run ldconfig which automatically switches over to the newly installed libraries. To go back to the packaged version you MUST uninstall your built version. Correct, that would happen if /usr/local was NOT in ldconfig's search path. That's why it really should be in the path if users are to build their own software. Tim.

termtech wrote It does not work in my OS (Fedora), After installing jack to /usr/local and ldconfig, the old jack (rpm-based) is launched. I have /usr/local/bin in my PATH before /user/bin. Setting LD_LIBRARY_PATH to a directory with jack libraries also does not have any effect. The only workable solution I found is building my own rpm and updating the system installed jack -- Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

On Sun, July 15, 2018 20:13, j(a)jrigg.co.uk wrote: I've been using that method as well, it works pretty good. Overwriting the distro package's files also circumvents a lot of package dependency issues. You could have jack installed from source and the repo jack package will most likely be pulled in sooner or later as a dependency by another package anyways. In a perfect world, there should be no reason that a preferred parallel installation in /usr/local would not work *for every client* that does not dlopen from a fixed location or otherwise tamper with the linker ($LD_LIBRARY_PATH etc). It has the advantage of not caring to re-install the compiled version after updates. Using 'ldd' on binaries to check which libraries are going to be used is an easy way to predict what will happen. In any case, checking which libraries are effectively somewhere on the system is always good advice. 'sudo updatedb && locate libjack' followed by selective removes and re-installs. Greetings Thomas

The right way of starting jackd compiled locally without installing it systemwide is env LD_LIBRARY_PATH=build/common JACK_DRIVER_DIR=build build/jackd ... For example: env LD_LIBRARY_PATH=build/common JACK_DRIVER_DIR=build build/jackd -v -R -P40 -p512 -t5000 -dalsa -d hw:Pro -r 48000 -p 1024 -n 2 -s -P -- Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html