Am 20.09.20 um 08:29 schrieb Jeanette C.: This section of the wiki page should really be updated. The first method listed there, of setting up the bridge between JACK and Pulseaudio, is IMHO not really the best. The author of Cadence itself does recommend not using it anymore and there is a stripped down replacement in the pipeline. As it is now, it executes a custom script to set up the JACK-Pulseaudio bridge, which bypasses the global and/or user configuration for the Pulseaudio modules "module-jack-sink" resp "module-jack-source". When it starts the pulseaudio daemon itself, it uses a custom configuration for it, which is different from them global or user one. This may lead to confusion when trying to change the Pulseaudio configuration, because changes to the global or user configuration might or might not take effect when using Cadence to set up Pulseaudio. In short, I recommend the setup described in the section "The manual sink configuration method", which is really the least manual of all, because, once configured, you just start JACK (jackdbus) via your preferred method (jack_control, qjackctl, jack-select, etc.) and everything else happens automatically (i.e. Pulseaudio relinquishes access to the audio device and the Pulseaudio-JACK bridge is set up and it's ports are connected). Chris

Am 23.09.20 um 05:43 schrieb david: a) There will be stripped down version of Cadecne coming hopefully at the end of this year. I don't know whether the JACK / Pulseaudio setup part will remain the same. b) You *can* use Cadence, just be aware that the Pulseaudio config it creates and uses may not be the same as when you run Pulseaudio by other means. The setup I describe works the same, only it doesn't matter whether Pulseaudio hat grabbed the audio device before JACK started. This way, Pulseaudio clients, i.e. your browser, can use your audio device via Pulseaudio while JACK is not running and Pulseaudio will access the device directly, but when JACK is started, Pulsesaudio will be routed to JACK. Normally, the even an already playing audio stream switches seamlessly from the Pulseaudio audio sink for the device to the new Pulseaudio JACK sink when JAKC is started. Chris

On Wed, September 23, 2020 4:36 pm, Ken Dawson wrote: Pipewire is intended to replace jackd, not work with jackd. The intended uses cover both PulseAudio use cases and jackd use cases (it implements the JACK API, so should be a drop in replacement when fully working properly). Available now in Fedora 32 for experimentation. -- Chris Caudle

On Thu, 24 Sep 2020 07:57:14 -0500 "Chris Caudle" <chris(a)chriscaudle.org> wrote: Looks very positive. I notice someone asked about auto reconnecting audio devices. If that can be done it would be fantastic. I've had a few wobbly USB plugs/sockets in the past! -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

Or Debian, and either one without any dependencies on the GNOME desktop evironment. On September 24, 2020 2:21:45 PM HST, Bob van der Poel <bob(a)mellowood.ca> wrote: --- David W. Jones gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com Sent from my Android device with F/LOSS K-9 Mail.

On Fri, 25 Sep 2020, Roger wrote: Agree. However, pipewire does not need flatpacks to run, so far as I know. Second, I think it is the wave of the future if we like it or not. I would not expect continued development on pulse which means it will die of bitrot soon enough. So at the very least pipewire will replace your pulse part of things. pipewire will bridge itself to another running jack instance so that may well work for you. In this case I would not agree. The pulse-jack bridge is problematic. When the bridge is running, pulse is forced to run at jack's latency which breaks some desktop applications at lower latencies and uses a lot of cpu (about twice as much as jack at any one latency). Pulse also syncs it's jack calls to any physical device it may find that jack is not using causing xruns and breaking freewheel mode in some cases. (removing all alsa modules from pulse fixes this) The pipewire desktop to jack bridging is properly buffered which fixes these problems. Also, pipewire does not run desktop-jack bridges except while needed and there is an actual connection. How good pipewire will be remains to be seen but it does look promising so far. -- Len Ovens www.ovenwerks.net

On Fri, 25 Sep 2020 at 14:27, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote: Each app decides what kind of latency it wants, PipeWire dynamically adjusts the graph buffer size (and latency) to the lowest requested latency. The PipeWire replacement libraries can handle the same low latency as jack clients. They are in fact very similar to a jack client with some adapter and converters added to make sure the pulse apps are not woken up too often. So if ardour runs at 32 sample buffers and you have a browser linked as an input, PipeWire will pull 32 samples from the sample queue in the pulse layer from the browser and push them into the ardour ports. The browser gets woken up after 32*N samples got pulled to match its requested latency so we don't wake it up more often than it requested. Wim