Jack 1 vs. 2

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Jack 1 vs. 2

Brent Busby
This subject seems to come up occasionally...

What is the current best practice with regard to Jack classic versus
Jack 2?  It's usually said that Jack 2 is optimized for SMP, but it's
hard to find a machine these days that isn't SMP.  Maybe the two
projects are merging because of this?

Because, Jack 1 hasn't gone away.  In fact, the only version of
jack-audio-connection-kit currently in Gentoo (no overlay) has a version
string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
overlay with 1.9.12 that I've been using, so I can fight this of
course...but should I?  Is everyone being advised to move to Jack 1 now?
For what it's worth in deciding, I prefer not to use dbus for control
(or for anything at all, when I can avoid it), and I'm using QJackCtl as
a frontend.
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Brandon Hale
I think it depends on preference. Jack2 is multi-threaded, and I've
found that some software work better with it (Radium in particular). I
think if you're unsure, go with Jack2. I'm not really much of user of
Jack1, so maybe other people who are more knowledgeable will have to
correct me, but Jack2 seems to work with less xruns on my machine and
seems more performant on my hardware.

Also, if you don't want to use d-bus with Jack2, you can disable it from
qjackctl's Setup > Misc options.

Brandon Hale

On 2/4/21 5:31 PM, Brent Busby wrote:

> This subject seems to come up occasionally...
>
> What is the current best practice with regard to Jack classic versus
> Jack 2?  It's usually said that Jack 2 is optimized for SMP, but it's
> hard to find a machine these days that isn't SMP.  Maybe the two
> projects are merging because of this?
>
> Because, Jack 1 hasn't gone away.  In fact, the only version of
> jack-audio-connection-kit currently in Gentoo (no overlay) has a version
> string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
> overlay with 1.9.12 that I've been using, so I can fight this of
> course...but should I?  Is everyone being advised to move to Jack 1 now?
> For what it's worth in deciding, I prefer not to use dbus for control
> (or for anything at all, when I can avoid it), and I'm using QJackCtl as
> a frontend.
> _______________________________________________
> Linux-audio-user mailing list
> [hidden email]
> https://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Brandon Hale

Just wanted to say, there is this page as well that talks about both of them.

On 2/4/21 5:40 PM, Brandon Hale wrote:
I think it depends on preference. Jack2 is multi-threaded, and I've found that some software work better with it (Radium in particular). I think if you're unsure, go with Jack2. I'm not really much of user of Jack1, so maybe other people who are more knowledgeable will have to correct me, but Jack2 seems to work with less xruns on my machine and seems more performant on my hardware.

Also, if you don't want to use d-bus with Jack2, you can disable it from qjackctl's Setup > Misc options.

Brandon Hale

On 2/4/21 5:31 PM, Brent Busby wrote:
This subject seems to come up occasionally...

What is the current best practice with regard to Jack classic versus
Jack 2?  It's usually said that Jack 2 is optimized for SMP, but it's
hard to find a machine these days that isn't SMP.  Maybe the two
projects are merging because of this?

Because, Jack 1 hasn't gone away.  In fact, the only version of
jack-audio-connection-kit currently in Gentoo (no overlay) has a version
string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
overlay with 1.9.12 that I've been using, so I can fight this of
course...but should I?  Is everyone being advised to move to Jack 1 now?
For what it's worth in deciding, I prefer not to use dbus for control
(or for anything at all, when I can avoid it), and I'm using QJackCtl as
a frontend.
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user

_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Fons Adriaensen-3
In reply to this post by Brent Busby
On Thu, Feb 04, 2021 at 04:31:05PM -0600, Brent Busby wrote:

> It's usually said that Jack 2 is optimized for SMP

'optimized for SMP' is somewhat misleading.

If you parallel paths, e.g

   A -> X -> B
   A -> Y -> B

or even as simple as

   X -> playback
   Y -> playback

then Jack2 will run X and Y at the same time if you have 2
or more CPUs, and Jack1 won't do that.

Another difference is that Jack1 sometimes runs clients out
of order - it uses the wrong algorithm to compute this.
For the first example above it could e.g. run X before A.
In many cases you won't notice the problem and that's why
this remained undetected until it hit me. I wasted a lot of
time trying to find the error in my code, until the only way
to explain things was to assume that Jack1 was the problem.
Patches to fix this (and some other problems) were rejected.

Otoh, I never managed to get even a minimal understanding
of Jack2's code, it's the sort of C++ that I prefer not to
touch.

--
FA

_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Arve Barsnes
In reply to this post by Brent Busby
On Thu, 4 Feb 2021 at 23:32, Brent Busby <[hidden email]> wrote:
> Because, Jack 1 hasn't gone away.  In fact, the only version of
> jack-audio-connection-kit currently in Gentoo (no overlay) has a version
> string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
> overlay with 1.9.12 that I've been using, so I can fight this of
> course...but should I?

The jack 2 version in the official repository is media-sound/jack2, no
need for any overlay.

Regards,
Arve
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Peter P.-2
In reply to this post by Fons Adriaensen-3
* Fons Adriaensen <[hidden email]> [2021-02-05 00:12]:

> On Thu, Feb 04, 2021 at 04:31:05PM -0600, Brent Busby wrote:
>
> > It's usually said that Jack 2 is optimized for SMP
>
> 'optimized for SMP' is somewhat misleading.
>
> If you parallel paths, e.g
>
>    A -> X -> B
>    A -> Y -> B
>
> or even as simple as
>
>    X -> playback
>    Y -> playback
>
> then Jack2 will run X and Y at the same time if you have 2
> or more CPUs, and Jack1 won't do that.
>
> Another difference is that Jack1 sometimes runs clients out
> of order - it uses the wrong algorithm to compute this.
> For the first example above it could e.g. run X before A.
> In many cases you won't notice the problem and that's why
> this remained undetected until it hit me. I wasted a lot of
> time trying to find the error in my code, until the only way
> to explain things was to assume that Jack1 was the problem.
> Patches to fix this (and some other problems) were rejected.
>
> Otoh, I never managed to get even a minimal understanding
> of Jack2's code, it's the sort of C++ that I prefer not to
> touch.

Thanks for this nice explanation Fons! Now which version are you using
in the end? Have you reported a bug report which I could read to
understand the problem better? Are you able to compile your own jack1
with your patch(es) applied and does it fix your problem?

cheers, P
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Brent Busby
In reply to this post by Arve Barsnes
Arve Barsnes <[hidden email]> writes:

> On Thu, 4 Feb 2021 at 23:32, Brent Busby <[hidden email]> wrote:
>> Because, Jack 1 hasn't gone away.  In fact, the only version of
>> jack-audio-connection-kit currently in Gentoo (no overlay) has a version
>> string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
>> overlay with 1.9.12 that I've been using, so I can fight this of
>> course...but should I?
>
> The jack 2 version in the official repository is media-sound/jack2, no
> need for any overlay.

I found that out earlier today, but thanks.  I'd been using my own local
overlay for so long that I hadn't been keeping track of what the distro
was calling it.
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Fons Adriaensen-3
In reply to this post by Peter P.-2
On Fri, Feb 05, 2021 at 09:43:07AM +0100, Peter P. wrote:

> Now which version are you using in the end?

On the machines I use for audio I'm using jack2 for the simple
reason that I run quite heavy things that could easily be too
much without multithreading, and that also tend to trigger the
running order problem.

Re. the latter: most users will never be affected by this bug,
with 'normal' use it is quite unlikely to manifest itself.
But if you have parallel paths and one of the clients is removed
and re-inserted a number of times (e.g. during development of
that client) it will show up. Also if you have number of clients
that run permanently (things like zita-mu1, ambisonic decoders,
xover filters, etc.) and others that come and go and connect
to the permanent ones.

> Have you reported a bug report which I could read to
> understand the problem better?

It was reported (along with a patch) to the Jack1 devs years
ago (I was still in Parma IIRC). Don't know if there are any
records of this apart form my own.

> Are you able to compile your own jack1 with your patch(es)
> applied and does it fix your problem?

Yes. But the patch is quite big, it affects a number of source
files and can't be factored into smaller ones. I had to create
some new internal data structures and modify some others, and
that meant that everything that depended on the old ones had
to be modified as well. Some changes could have been avoided,
but that would have meant having two data sets representing
the same state and needing to be kept in sync. That is bad
design and a sure recipe for future trouble, so I was quite
motivated to clean up the mess.
The essential changes also exposed a lot of very inefficient
algorithms. For example, if you make a new connection between
two clients that are already connected then there is no need
to recompute the running order, but it was done anyway just
because the existing logic required it. It doesn't matter if
you have just a few clients with a few ports. But this doesn't
scale well to bigger systems. So I decided to fix that at the
same time. That's probably why the patch was rejected.

Ciao,

--
FA

_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Filipe Coelho-2
On 05/02/21 10:41, Fons Adriaensen wrote:
> The essential changes also exposed a lot of very inefficient
> algorithms. For example, if you make a new connection between
> two clients that are already connected then there is no need
> to recompute the running order, but it was done anyway just
> because the existing logic required it. It doesn't matter if
> you have just a few clients with a few ports. But this doesn't
> scale well to bigger systems. So I decided to fix that at the
> same time. That's probably why the patch was rejected.

The patch was rejected because it contained superfluous whitespace
changes, code style changes that did no changes to the actual code and
other things typical of a "here is a big patch which I didnt bother
cleanup" dump of a diff.

Paul Davis went to the trouble of converting the *entire* jack1 codebase
with an automated code styling tool (so all the code would have the same
rules on coding style) just so we could have your patch in the codebase.
Idea of the process being:
1. convert entire jack1 code to a specific style [1]
2. apply your (unclean) patch in a different jack1 copy and convert that
entire codebase too
3. make a diff out of the 2 to have a clean patch [2]

It turns out the end result did not work well, so it had to be reverted [3]

There would have been no issues if the patch was properly made from the
start.
Paul went to the extra effort of cleaning up the entire codebase just to
accept the patch from you, but somehow that didnt work (why exactly I
dont know).


[1]
https://github.com/jackaudio/jack1/commit/c758cdf4f6e959b92683f2dba6ce8617ac4f0a83
[2]
https://github.com/jackaudio/jack1/commit/423931219dd3e3b669fde97786cadae92c066dc1
[3]
https://github.com/jackaudio/jack1/commit/ea78c7e06e768a02d6129c43c51473a7f94cfd73
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Rui Nuno Capela
On 2/5/21 10:54 AM, Filipe Coelho wrote:

> On 05/02/21 10:41, Fons Adriaensen wrote:
>> The essential changes also exposed a lot of very inefficient
>> algorithms. For example, if you make a new connection between two
>> clients that are already connected then there is no need to
>> recompute the running order, but it was done anyway just because
>> the existing logic required it. It doesn't matter if you have just
>> a few clients with a few ports. But this doesn't scale well to
>> bigger systems. So I decided to fix that at the same time. That's
>> probably why the patch was rejected.
>
> [...]
>
> It turns out the end result did not work well, so it had to be
> reverted [3]
>
 > [3]
https://github.com/jackaudio/jack1/commit/ea78c7e06e768a02d6129c43c51473a7f94cfd73

IIRC, Fons' "topological sort" patch was reverted just because the end
result were **audibly** worse that not, for most "normal" situations.

It wasn't quite about code style... you could actually **hear** the
damage to your ears! :)

cheers
--
rncbc aka. Rui Nuno Capela
[hidden email]
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Fons Adriaensen-3
In reply to this post by Filipe Coelho-2
On Fri, Feb 05, 2021 at 10:54:23AM +0000, Filipe Coelho wrote:

> 1. convert entire jack1 code to a specific style [1]
> 2. apply your (unclean) patch in a different jack1 copy and convert that
> entire codebase too
> 3. make a diff out of the 2 to have a clean patch [2]
> It turns out the end result did not work well, so it had to be reverted [3]

It certainly worked very here and was used to run some very big
systems for years without any problem. I only switched to Jack2
later in order to have the advantage of multiple CPUs.

> Paul went to the extra effort of cleaning up the entire codebase just to
> accept the patch from you, but somehow that didnt work (why exactly I dont
> know).

I should probably have presented the entire modified source
instead of patch. Test it, if it works just check it in and
let the version control system find the deltas. Clean up
the style afterwards if you want.

The 1,2,3 above is quite a fragile process, I'm not surprised
it didn't work out well.

I went to the trouble of reformatting some of the original code
just to be able to read and understand it, which would have been
near impossible otherwise. It was only done where the e.g. the
indentation was wrong, sometimes spanning multiple screens, and
utterly misleading in the original. Or where I had to strain my eyes
trying to parse verylongstringsconsistingofvariablenamesandmathoperatorswithoutanywhitespace.

The original code wasn't clean to start with.

Ciao,

--
FA


_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Fons Adriaensen-3
In reply to this post by Peter P.-2
On Fri, Feb 05, 2021 at 09:43:07AM +0100, Peter P. wrote:

> Are you able to compile your own jack1
> with your patch(es) applied and does it fix your problem?

Reviewing the notes I made at the time, there was actually
a second step planned but never executed.

The new algorithm to find the running order was much simpler
than the original - it maintained a very light data structure
representing the dependencies between clients and therefore
didn't require scanning all port connections as did the
original.

That meant it could be run inside the processing cycle and
trigger clients in real time, without any significant overhead,
instead of creating a list. This would have made Jack1
multithreaded, providing the same advantages as Jack2.

After the patch was rejected I lost interest, so this was
never tried, at least not in Jack1.

Ciao,

--
FA


_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Max
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Max
In reply to this post by Brent Busby
Interesting thread.
Out of curiosity: How does pipewire relate here? Since it claims to be a
replacement for jack and pulseaudio but jack1 and jack2 coexist, does it
replace jack1 or 2?

m.



On 04.02.21 23:31, Brent Busby wrote:

> This subject seems to come up occasionally...
>
> What is the current best practice with regard to Jack classic versus
> Jack 2?  It's usually said that Jack 2 is optimized for SMP, but it's
> hard to find a machine these days that isn't SMP.  Maybe the two
> projects are merging because of this?
>
> Because, Jack 1 hasn't gone away.  In fact, the only version of
> jack-audio-connection-kit currently in Gentoo (no overlay) has a version
> string of 0.125.0-r1, and I presume that's Jack 1.  I've got a local
> overlay with 1.9.12 that I've been using, so I can fight this of
> course...but should I?  Is everyone being advised to move to Jack 1 now?
> For what it's worth in deciding, I prefer not to use dbus for control
> (or for anything at all, when I can avoid it), and I'm using QJackCtl as
> a frontend.
> _______________________________________________
> Linux-audio-user mailing list
> [hidden email]
> https://lists.linuxaudio.org/listinfo/linux-audio-user
>
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Chris Caudle-2
On 2021-02-08 09:14, Max wrote:
> Interesting thread.
> Out of curiosity: How does pipewire relate here? Since it claims to be
> a replacement for jack and pulseaudio but jack1 and jack2 coexist,
> does it replace jack1 or 2?

Pipewire implements the JACK API, similar to jackd v1 implements JACK
API and jackd v2 also implements JACK API.
Ideally any implementation of the JACK API should be interchangeable,
with the choice based on what specific features each implementation
provides.
Pipewire also implements the pulseaudio API, which should help with
people that would like to run normal system applications like a music
player or web browser at the same time as applications which use jack
(as well as implementing something similar for video applications).  
Note that pipewire is still in development, so is not yet considered
ready for use in critical situations.

You should only run one JACK audio server at a time, so pipewire, OR
jackd v1, OR jackd v2.    Thinking of either of the three as
specifically replacing one or both of the other JACK  API
implementations isn't quite accurate, although at one time some people
thought jackd v2 would end up replacing jackd v1.  For various reasons
both continued in parallel, and that will likely be the same with
pipewire, some distributions will switch to pipewire when it is mature,
some will not, and some will provide ways to choose which implementation
you want to use.

--
Chris Caudle
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Bengt Gördén-3
In reply to this post by Max
On 2021-02-08 16:14, Max wrote:
> Interesting thread.
> Out of curiosity: How does pipewire relate here? Since it claims to be a
> replacement for jack and pulseaudio but jack1 and jack2 coexist, does it replace
> jack1 or 2?

I have no special insight in pipewire but I believe it's JACK API they mean and
not the specific implementations. In that sense pipewire behaves like a thirds
version of jack (jack3). But there is certainly some differences behind the
scene. And some things aren't there yet.

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Limitations-in-0.3


--
/bengan
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: Jack 1 vs. 2

Len Ovens
In reply to this post by Max
On Mon, 8 Feb 2021, Max wrote:

> Interesting thread.
> Out of curiosity: How does pipewire relate here? Since it claims to be a
> replacement for jack and pulseaudio but jack1 and jack2 coexist, does it
> replace jack1 or 2?

it shows promise but is not there yet. Jack2 (I do not know if jack1 is
also able to ask pulse to release a device) at least will be able to ask
for a device from PW and so run along side. PW can bridge, as a jack
client, to a running jack. It can run as jack... but so far no ability to
load the ffado back end. The alsa fireworks module seems broken since
after 5.4 (5.4 works but 5.8-5.11 do not) and so pw as a jack replacement
is not an option for me. Unfortunately USB audio is not a replacement for
a FW device running the FFADO modules in stability, perhaps the way JACK
deals with ALSA needs a revisit or maybe alsa in general needs a look with
an eye towards lower latency use.

So when pw is finished (if it gets that far), it should effectively be a
drop in replacement for jack2 with a pulse frontend. With the added
ability to have it's parameters changed on the fly in a more stable manner
than JACK2 does now. It should be noted however, that many JACK clients do
not deal with JACK parameter changes very well. There are very few that
can just keep going (guitarix handles this about the best I think). The
better ones might just drop JACK ports and complain, some exit gracefully
and some just do wierd things until restarted. I think the best thing to
do is to choose a studio sample rate and frame size and stick with it. At
last make any changes before starting jack applications and utilities.


--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-user