On Fri, Feb 05, 2021 at 09:43:07AM +0100, Peter P. wrote: 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. 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. 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

On 2/5/21 10:54 AM, Filipe Coelho wrote: https://github.com/jackaudio/jack1/commit/ea78c7e06e768a02d6129c43c51473a7f… 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 rncbc(a)rncbc.org

On Fri, Feb 05, 2021 at 09:43:07AM +0100, Peter P. wrote: 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

Arve Barsnes <arve.barsnes(a)gmail.com> writes: 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.

On 2021-02-08 09:14, Max wrote: 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

On Mon, 8 Feb 2021, Max wrote: 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