[Jack-Devel] How to profile jack cpu load?

[oleg68]

Hello.

I use jackd with some music applications and patchbay. After some time after
starting the jack cpu load (according to QJackCtl) becomes 100%, the last
sound (or silence) pins and no more sound appearrs.

I'd like to investigate this situation and to find, which jack client
application consumes CPU. Looking at the jack sourcecode I found
JackEngineProfiling hich seams makes some measuring. But I could not find
how to use this feature?

Ho can I search the distinct CPU load by each jack client application?




--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

[Joakim Hernberg]

You have to rebuild JACK2 with the --profiling option.

It's also a fixed buffer, so it only works for a while after starting
the server.

You can get nice graphs for the results too, see:
http://www.grame.fr/ressources/publications/Timing.pdf


On Sat, 7 Jul 2018 10:56:21 -0700 (MST)
oleg68 <***@gmail.com> wrote:

> Hello.
>
> I use jackd with some music applications and patchbay. After some
> time after starting the jack cpu load (according to QJackCtl) becomes
> 100%, the last sound (or silence) pins and no more sound appearrs.
>
> I'd like to investigate this situation and to find, which jack client
> application consumes CPU. Looking at the jack sourcecode I found
> JackEngineProfiling hich seams makes some measuring. But I could not
> find how to use this feature?
>
> Ho can I search the distinct CPU load by each jack client application?
>
>
>
>
> --
> Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
> _______________________________________________
> Jack-Devel mailing list
> Jack-***@lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



--

Joakim

[oleg68]

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

[Daniel Farmer]

This post might be inappropriate. Click to display it.

[David Kastrup]

Daniel Farmer <***@outlook.com> writes:

> They should call it "jack shit" because that's all it does.

Let me guess how much you contributed to its code and documentation.
And likely the code and documentation of any Free Software, given that
entitlement attitude and this show of respect.

--
David Kastrup

[John Rigg]

On Sun, Jul 08, 2018 at 06:10:05PM +0000, Daniel Farmer wrote:
> They should call it "jack shit" because that's all it does.
>
>
> Jack Shit.

This post tells me all I need to know about your competence
as an audio engineer and/or developer. Sometimes it's better
to keep your mouth shut and hope nobody notices you're an
idiot, rather than opening it and advertising the fact.

John

[Tim]

> When I started jackd with -v option, there no message "Engine
profiling activated" in the standard output.
> When I set the brakpoint at JackEngineProfiling::JackEngineProfiling() with a debugger, this breakpoint is never > >reached.

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.

[Joakim Hernberg]

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 <***@gmail.com> wrote:

> 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
> _______________________________________________
> Jack-Devel mailing list
> Jack-***@lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org



--

Joakim

[Chris Caudle]

On Sun, July 8, 2018 1:57 pm, Joakim Hernberg wrote:
> JACK2 isn't really maintained anymore, but hopefully that
> will change in the future.

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

[Joakim Hernberg]

On Sun, 8 Jul 2018 14:28:14 -0500
"Chris Caudle" <***@chriscaudle.org> wrote:

> On Sun, July 8, 2018 1:57 pm, Joakim Hernberg wrote:
> > JACK2 isn't really maintained anymore, but hopefully that
> > will change in the future.
>
> 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.

That's why I wrote "isn't really maintained".. I am aware that falktx
has taken on the maintainership, and hopefully the future will bring
improvements.

The point was that JACK2 even though it had a maintainer
before falktx was somewhat bit rotting and not getting any real
development, while JACK1 got updates as long as Paul was maintaining
it.

Just thought it was a possibility that profiling was also something not
working properly anymore.

I suppose I should have chosen other words to avoid misunderstanding :)

--

Joakim

[Kjetil Matheussen]

On Mon, Jul 9, 2018 at 1:37 PM, Joakim Hernberg <***@alchemy.lu>
wrote:

> On Sun, 8 Jul 2018 14:28:14 -0500
> "Chris Caudle" <***@chriscaudle.org> wrote:
>
> > On Sun, July 8, 2018 1:57 pm, Joakim Hernberg wrote:
> > > JACK2 isn't really maintained anymore, but hopefully that
> > > will change in the future.
> >
> > 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.
>
> That's why I wrote "isn't really maintained".. I am aware that falktx
> has taken on the maintainership, and hopefully the future will bring
> improvements.
>
> The point was that JACK2 even though it had a maintainer
> before falktx was somewhat bit rotting and not getting any real
> development, while JACK1 got updates as long as Paul was maintaining
> it.
>
> Just thought it was a possibility that profiling was also something not
> working properly anymore.
>
> I suppose I should have chosen other words to avoid misunderstanding :)
>
>
This seems like FUD. If something isn't working, report it. Few updates
doesn't
mean that it's "bit rotting" or "isn't really maintained". If something
works
as it should, it doesn't need updates.

[John Rigg]

On Sun, Jul 08, 2018 at 08:35:53PM +0000, Daniel Farmer wrote:
> So funny. Jack Shit is shitty and shitty developers start telling me how much I suck because they can't take responsibility for their crappy programming "skills".
>
> If you developers were so great we'd at least have "Jack is the shit"
>
>
> But right now all we have is "Jack Shit".
>
>
> LOLOLOLOLOLOLOLOLOLOL

I guess this is an example of how Linux audio software has
become a victim of its own success.

I've been using jackd for audio work since 2005. Up until
recently the level of discussion on most of the Linux audio
mailing lists was quite high. Over the last three or four
years I've gradually unsubscribed from most of them as
they've become unusable due to adolescent behaviour like
the above.

I was hoping jack-devel wouldn't succumb like the others.
Pity.

John

[Kjetil Matheussen]

On Sun, Jul 8, 2018 at 9:13 AM, oleg68 <***@gmail.com> wrote:

> 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?
>
>
Maybe you have to set JACK_CLIENT_DEBUG to 1?

[Joakim Hernberg]

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

[Stéphane Letz]

This post might be inappropriate. Click to display it.

[Joakim Hernberg]

Managed to only send this offlist, trying agian.

On Tue, 10 Jul 2018 12:36:50 +0200
Stéphane Letz <***@grame.fr> wrote:

> It seems that « shit still works… »

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

[oleg68]

I'd maken a file test.sh, that downloads, builds and runs jackd.
------------------------------------------
#/usr/bin/sh
rm -rf jack2
git clone git://github.com/jackaudio/jack2.git
cd jack2
./waf configure --profile
./waf build
echo
echo "Running jackd"
build/jackd -v -R -P40 -dalsa -d hw:Pro -r 48000 -p 1024 -n 2 -s -P
------------------------------------------

Than I ran:

./test.sh | tee test.log

The resulting test.log
<http://jack-audio.10948.n7.nabble.com/file/t1525/test.log> does not
contain any 'Engine profiling activated' message



--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

[Tim]

On 07/13/2018 04:21 PM, oleg68 wrote:
> I'd maken a file test.sh, that downloads, builds and runs jackd.
> ------------------------------------------
> #/usr/bin/sh
> rm -rf jack2
> git clone git://github.com/jackaudio/jack2.git
> cd jack2
> ./waf configure --profile
> ./waf build
> echo
> echo "Running jackd"
> build/jackd -v -R -P40 -dalsa -d hw:Pro -r 48000 -p 1024 -n 2 -s -P
> ------------------------------------------
>
> Than I ran:
>
> ./test.sh | tee test.log
>
> The resulting test.log
> <http://jack-audio.10948.n7.nabble.com/file/t1525/test.log> does not
> contain any 'Engine profiling activated' message


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.

[oleg68]

You are right. The problem was the conflict with the old jack libraries

But .waf install with ldconfig did not help.

I solved this problem after building the rpm package
jack-audio-connection-kit for my operating system with profiling enabled and
updating the installed jack-audio-connection-kit with the new one.

Now I can see the message

'Engine profiling activated, beware 783 MBytes are needed to record
profiling points...'




--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

[John Rigg]

On Sat, Jul 14, 2018 at 12:41:28AM -0700, oleg68 wrote:
> You are right. The problem was the conflict with the old jack libraries
>
> But .waf install with ldconfig did not help.

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

[Tim]

On 07/14/2018 04:15 AM, John Rigg wrote:
> On Sat, Jul 14, 2018 at 12:41:28AM -0700, oleg68 wrote:
>> You are right. The problem was the conflict with the old jack libraries
>>
>> But .waf install with ldconfig did not help.
>
> 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

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.

>
> Your distro may use different locations, but it's easy
> to check.
>
> John

[Chris Caudle]

On Sat, July 14, 2018 11:52 am, Tim wrote:
> Two versions of Jack can happily coexist - one in /usr
> and one in /usr/local.

Paul always warned strongly against that. How do you make sure the one in
usr is not used?
The recommendation I had always heard when using something like Fedora
which would try to remove a lot of packages if you removed the system
provided RPM was to just delete the files manually, without touching the
RPM database, then install the locally built version.
Maybe you found a method that works reliably, but in the past at least
even the jackd developers wouldn't trust leaving the distribution provided
files on the filesystem.

--
Chris Caudle

[David Kastrup]

"Chris Caudle" <***@chriscaudle.org> writes:

> On Sat, July 14, 2018 11:52 am, Tim wrote:
>> Two versions of Jack can happily coexist - one in /usr
>> and one in /usr/local.
>
> Paul always warned strongly against that. How do you make sure the one in
> usr is not used?

Putting /usr/local/bin first in PATH ? I do that kind of thing
frequently.

> The recommendation I had always heard when using something like Fedora
> which would try to remove a lot of packages if you removed the system
> provided RPM was to just delete the files manually, without touching
> the RPM database, then install the locally built version.

I don't think that bullshitting RPM is really the way to go.

--
David Kastrup

[Chris Caudle]

On Sat, July 14, 2018 1:57 pm, David Kastrup wrote:
> "Chris Caudle" <***@chriscaudle.org> writes:
>> How do you make sure the one in
>> usr is not used?
>
> Putting /usr/local/bin first in PATH ?

The PATH environment variable only controls where you search for
executables, not shared libraries.
https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime
https://unix.stackexchange.com/questions/171632/where-will-the-system-search-for-dynamic-libraries
https://en.wikipedia.org/wiki/Rpath
http://man7.org/linux/man-pages/man8/ld.so.8.html

Notice in the ld man page that executables can have a search path in the
ELF header. The executables DT_RUNPATH value comes before the
LD_LIBRARY_PATH environment variable in the search order.

Seems like there are several ways that loading the newly compiled version
could go wrong if the older files are still present.

--
Chris Caudle

[Tim]

On 07/14/2018 02:47 PM, Chris Caudle wrote:
> On Sat, July 14, 2018 11:52 am, Tim wrote:
>> Two versions of Jack can happily coexist - one in /usr
>> and one in /usr/local.
>
> Paul always warned strongly against that. How do you make sure the one in
> usr is not used?

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.

> The recommendation I had always heard when using something like Fedora
> which would try to remove a lot of packages if you removed the system
> provided RPM was to just delete the files manually, without touching the
> RPM database, then install the locally built version.
> Maybe you found a method that works reliably, but in the past at least
> even the jackd developers wouldn't trust leaving the distribution provided
> files on the filesystem.
>

[Chris Caudle]

On Sat, July 14, 2018 2:21 pm, Tim wrote:
> 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

I still don't follow how the applications (e.g. Ardour) get the correct
version of libjack.so loaded, /usr/local isn't even in the default ld
search path. Putting a locally compiled version of jackd into
/usr/local/bin seems like a recipe for loading a new jackd executable
while having the jack-aware applications load the libjack.so that is found
in /usr/lib64/. Am I missing something about how the shared libraries get
loaded?

--
Chris Caudle

[Tim]

On 07/14/2018 03:28 PM, Chris Caudle wrote:
> On Sat, July 14, 2018 2:21 pm, Tim wrote:
>> 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
>
> I still don't follow how the applications (e.g. Ardour) get the correct
> version of libjack.so loaded, /usr/local isn't even in the default ld
> search path.

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.

> Putting a locally compiled version of jackd into
> /usr/local/bin seems like a recipe for loading a new jackd executable
> while having the jack-aware applications load the libjack.so that is found
> in /usr/lib64/. Am I missing something about how the shared libraries get
> loaded?

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.

[Harry van Haaren]

On Sat, Jul 14, 2018 at 8:40 PM Tim <***@rogers.com> wrote:
> On 07/14/2018 03:28 PM, Chris Caudle wrote:
> > On Sat, July 14, 2018 2:21 pm, Tim wrote:
> >> 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
> >
> > I still don't follow how the applications (e.g. Ardour) get the correct
> > version of libjack.so loaded, /usr/local isn't even in the default ld
> > search path.
>
> Ah, terribly sorry, yes, some distros don't include that path.
> Others do. And they /should/.

Not that I think this is a good idea - but for completeness it is possible
to just compile JACK 1 or 2 locally (aka, no install to /usr/ or /usr/local)
and then us LD_PRELOAD to have the linker load the required .so's before
starting JACK.

This ain't pretty, but if there's no JACK .so's in LD_LIBRARY_PATH at all,
and you *must* manually specify them all the time, at least its human error
if things go wrong.

Re-hash; this is a "solution" that I don't really recommend in this case,
however LD_PRELOAD can be quiet useful in other situations (like the
magic of JACK Interposer : https://github.com/raboof/jack_interposer : )
hence my promoting it here.

<snip lots of conversation>

Regards, -Harry

--

http://www.openavproductions.com

[oleg68]

When I often recompile and debug jack, it is not convinient to install
modified jack systemwide. I'd prefer to run jack with it's libraries from
somewhere in the userspace.

When I try to start jack in this manner

export LD_LIBRARY_PATH=build:build/common
build/jackd -v -R -P40 -p512 -t5000 -dalsa -d hw:Pro -r 48000 -p 1024 -n 2
-s -P

I receive the following error message
------------------------------------------------
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
Could not open driver directory /usr/local/lib/jack: No such file or
directory
Could not find any drivers in driver directory!
Failed to create server object
------------------------------------------------------------------

Seems the necessary .so is loaded correctly, but there are some path where
jack searches its drivers. How can I redefine this path?




--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html

[oleg68]

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

[oleg68]

termtech wrote
> /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.

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

[j***@jrigg.co.uk]

On Sat, Jul 14, 2018 at 12:52:49PM -0400, Tim wrote:
>
>
> On 07/14/2018 04:15 AM, John Rigg wrote:
>> On Sat, Jul 14, 2018 at 12:41:28AM -0700, oleg68 wrote:
>>> You are right. The problem was the conflict with the old jack libraries
>>>
>>> But .waf install with ldconfig did not help.
>>
>> 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
>
> I would not recommended that. Always a bad idea.
> It will interfere with packaging.

I disagree that it's a bad idea. The whole point is that
other packages that depend on the distro's jack packages
still think those are installed. The only thing to watch for
is if you update the distro jack packages it will overwrite
the compiled version, so you'll have to re-install that.

I've been using this method for many years without problems.

John

[Thomas Brand]

On Sun, July 15, 2018 20:13, ***@jrigg.co.uk wrote:
> On Sat, Jul 14, 2018 at 12:52:49PM -0400, Tim wrote:
>
>>
>>
>> On 07/14/2018 04:15 AM, John Rigg wrote:
>>
>>> On Sat, Jul 14, 2018 at 12:41:28AM -0700, oleg68 wrote:
>>>
>>>> You are right. The problem was the conflict with the old jack
>>>> libraries
>>>>
>>>> But .waf install with ldconfig did not help.
>>>>
>>>
>>> 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
>>>
>>
>> I would not recommended that. Always a bad idea.
>> It will interfere with packaging.
>>
>
> I disagree that it's a bad idea. The whole point is that
> other packages that depend on the distro's jack packages still think those
> are installed. The only thing to watch for is if you update the distro
> jack packages it will overwrite the compiled version, so you'll have to
> re-install that.
>
> I've been using this method for many years without problems.
>
>

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

[oleg68]

I collected the profiling informaion profiling.zip
<http://jack-audio.10948.n7.nabble.com/file/t1525/profiling.zip>

How can I interprete this result? At the line 225 jack started sustaining
the sound and DSP load became 100%.

If the driver interrupt period became large, why the DSP load is high too?



--
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html