On Tue, Jan 25, 2022 at 3:37 PM Jeanette C. <julien(a)mail.upb.de> wrote: Again, PipeWire *is* JACK and it is also PulseAudio. It it not a replacement for PulseAudio, it is a replacement for both of them. Once you are using PipeWire, everything you've read about JACK bridging etc. becomes incorrect and irrelevant.

Jan 26 2022, Filipe Coelho has written: ... That is exactly what I would like to do. Apologies if I have expressed this technically vaguely. Any ideas on that? Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c 'Cause living in a dream of you and me Is not the way my life should be... <3 (Britney Spears)

Jan 26 2022, Paul Davis has written: ... OK. Given that perspective, I see that there is documentation, possibly even covering using an ALSA input/output that combines two soundcards. But from the docs it looks like the JACK thing really start at 0.3.44 with demo configurations and everything. I have 0.43 installed by the system. So there's a dilemma. :) Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c 'Cause living in a dream of you and me Is not the way my life should be... <3 (Britney Spears)

On 2022-01-25 16:02:29 (-0700), Paul Davis wrote: That is technically not necessarily true, as it depends on how the build of pipewire is configured (e.g. by default its JACK libraries are configured to be installed to a pipewire internal location and it does not install the header files) and how packages for a given distribution are created from it. On Arch Linux we have switched to a scenario where pipewire-jack (the JACK implementation of pipewire, which depends on pipewire) is a virtual provider of "jack". On Arch that also includes the headers, as we do not really split for -dev packages. The jack2 package also provides "jack" and therefore the two implementations conflict with one another and can not be installed side by side anymore. Switching between the implementations has become a bit easier now that we have jack-example-tools [1]. Pipewire can be installed without also having to install pipewire-jack or pipewire-pulse (the pulseaudio implementation of pipewire). This means that pipewire may be used on top of a different JACK implementation (e.g. jack2), which apparently is possible [2]. From a user's perspective I believe this gives the highest amount of flexibility to choose what they like. It is true though, that some statements in regards to workflows with JACK tooling might not hold when using pipewire-jack (e.g. pipewire-jack does not currently implement internal clients or dbus support). This is why I started a comparison table [3] for users to give a rough overview at least. Best, David [1] https://github.com/jackaudio/jack-example-tools [2] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK [3] https://wiki.archlinux.org/title/JACK_Audio_Connection_Kit#Comparison_of_JA… -- https://sleepmap.de

On Wed, 26 Jan 2022 at 15:30, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: Running PipeWire on top of JACK was something that was requested early on because firewire audio support was broken in the kernel and there was no other way to run that hardware otherwise. Now that this is largely fixed, running PipeWire on JACK is pretty pointless, confusing and no longer supported. I think I'm going to remove it in some future version... Wim

First, let me give kudos to Wim for coming on the list and interacting about this with the community! Much appreciated ;-) [...] Speaking of PipeWire as a potential JACK replacement, what's the status of JACK Transport? there are hints in the FAQ [1] and an old version of the Wiki [2] Am I the only one thinking that coupled with the more 'obvious' inter-connect-ability of any (jack-enabled) application, JACK transport is still a _really_ cool feature and one of the reasons I (maybe also other people) really like doing music/audio with Linux, i.e. using 'any' application you prefer to do a certain part of the job in both more traditional and experimental creative set-ups? Lorenzo [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ [2] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK?version_id=00…

On 27.01.22 09:42, Wim Taymans wrote: Are there any plans for porting PipeWire to other operating systems like windows or macOS? I think it is a great feature of jack that is available not only on Linux (despite the fact that my audio work is 100% linux-based). Giso

On Thu, Jan 27, 2022 at 10:37 AM Tim &lt;termtech(a)rogers.com&gt; wrote: Given that we've seen plugins explode because Ardour uses exponential tempo ramps (like humans do) rather than linear, I'm pessimistic.

On Thu, Jan 27, 2022 at 5:27 PM Tim &lt;termtech(a)rogers.com&gt; wrote: Let's suppose you are playing the simplest of beats, let's say you just play a note/tone at 120bpm. There's 0.5 seconds between your playing. To do a linear speedup, you would gradually reduce the time between notes, maybe like this: 0.5, 0.45, 0.40, 0.35, 0.30 and so on Problem is, it turns out that humans (even the musical among us) are not very good at all at measuring absolute time. What we are good at is measuring relative time, and so what actually happens is that we decrease (or increase) the "time per note" by a constant *factor*. Let's say the factor is 0.1. So now, the first note of our nominal accelarando is 0.45 long, but the next one is 0.405 then 0.3645 then 0.3285 and so forth. This forms a natural exponential progression. Put a different way, human performers do not speed up or slow down by a constant amount per beat of an accelerando or decelerando, they speed up or slow down by a constant ratio. This behavior has been noted in several research papers on human musical performance, and it is very, very difficult for most humans to do anything else. Alas, I have no specific info on this. x42/robin gareus might know more. Not many plugins care about the tempo map. The ones that do have a lot of potential for screwing up if they come with some baked in idea of "this is what accelerando sounds like".

Can somebody share pipewire configuration files for low latency audio with pw-jack ? I am still struggling but maybe this is due to the audio USB interface I've got: FocusRite 18i8. I now that there is a big problem of JACK playback with RT kernels 5.15 and 5.16 ... Maybe this card is not yet supported too by pipewire ... ----- Mail original ----- De: "Tim" &lt;termtech(a)rogers.com&gt; À: linux-audio-user(a)lists.linuxaudio.org Envoyé: Vendredi 28 Janvier 2022 07:14:11 Objet: Re: [LAU] Connect pipewire to running JACK server On 1/27/22 10:20 PM, Paul Davis wrote: On Thu, Jan 27, 2022 at 5:27 PM Tim < termtech(a)rogers.com > wrote: On 1/27/22 1:08 PM, Paul Davis wrote: Hiya Paul. Could you explain that a bit more? Human exponential vs. linear, I don't quite understand. Let's suppose you are playing the simplest of beats, let's say you just play a note/tone at 120bpm. There's 0.5 seconds between your playing. To do a linear speedup, you would gradually reduce the time between notes, maybe like this: 0.5, 0.45, 0.40, 0.35, 0.30 and so on Problem is, it turns out that humans (even the musical among us) are not very good at all at measuring absolute time. What we are good at is measuring relative time, and so what actually happens is that we decrease (or increase) the "time per note" by a constant *factor*. Let's say the factor is 0.1. So now, the first note of our nominal accelarando is 0.45 long, but the next one is 0.405 then 0.3645 then 0.3285 and so forth. This forms a natural exponential progression. Put a different way, human performers do not speed up or slow down by a constant amount per beat of an accelerando or decelerando, they speed up or slow down by a constant ratio. This behavior has been noted in several research papers on human musical performance, and it is very, very difficult for most humans to do anything else. And can you remember which types of, or specific, plugins would fail, and why? I'd like to investigate. Alas, I have no specific info on this. x42/robin gareus might know more. Not many plugins care about the tempo map. The ones that do have a lot of potential for screwing up if they come with some baked in idea of "this is what accelerando sounds like". OK cool thanks. Yeah I thought it might be something like that, a natural tempo factor per unit time. I'm sure there must be specific written or recorded exceptions though. Ironic: Right now I'm helping with a user's problem with a midi file song, "Hallelujah", which actually has a _linear_ tempo ramp-down at song end. I'm not so concerned with plugins, just basic time-line tempo and signature mirroring between apps. Although, you once warned me that different apps or plugins will have different ideas about it. that you now tend to prefer that. Well of course, given Ardour has had midi for a while now ;-) So it may be a moot feature these days, for any serious musical work. Unless one prefers modular projects? But before Ardour had midi, I longed for the day when our two apps could sit side-by-side and share a time-line. T. _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

Nice, thanks for the hint. I will do some tests next week. ----- Mail original ----- De: "David Kastrup" &lt;dak(a)gnu.org&gt; À: "ycollette nospam" &lt;ycollette.nospam(a)free.fr&gt; Cc: "Tim" &lt;termtech(a)rogers.com&gt;om>, linux-audio-user(a)lists.linuxaudio.org Envoyé: Vendredi 28 Janvier 2022 16:37:52 Objet: Re: [LAU] Connect pipewire to running JACK server ycollette.nospam(a)free.fr writes: It's maybe not overly relevant for your case but I've had significantly different experiences with, say, the Mackie Onyx Satellite and the ALSA drivers by picking period sizes of 128 (which does not work without periodic dropouts not marked as Xruns) and even something as low as 24 samples: apparently at least at 48kHz or 96kHz it is crucial to have the period size divisable by 3. And if it is, very low latencies are possible while if it isn't, you get garbage. -- David Kastrup

Yann Collette &lt;ycollette.nospam(a)free.fr&gt; writes: 192? 96? Yes and no. Some Windows ASIO drivers refused to do anything but that for some Behringer USB card and worked with stuff as ridiculously low as 24. And if you try converting period sizes to millisecs, you need that factor of 3. The Opus Codec has as smallest standard size 120 samples @48kHz (2.5msec) . Stuff like that. 48kHz needs that factor of 3 to map nicely to millisecs. It doesn't make a superb amount of sense to me I'll readily admit. Maybe the actual rule is "avoid powers of 2" for some drivers and/or hardware, and 3x2^n is about as far from a power of 2 as you can get. -- David Kastrup

On Fri, 28 Jan 2022, ycollette.nospam(a)free.fr wrote: JACK and Pipewire use ALSA to talk to the audio device. JACK is capable of stable operation at least to 16/2 _IF_ the hardware (both audio device and the computer) are capable of it. As above, if the device shows up in ALSA, it is already "supported". However, as a USB device it is competing with all other USB devices and newer kernels do not show interrupt processes as usb1, 2, 4, etc. In fact, they tend to group all usb 1.1 and usb 2.0 to one usb port anyway. As such, the only way to have a separate irq or irq process to prioritize, is to install a separate PCIe USB card just for that audio device (good luck with a laptop). The irq for that usb card can then be prioritized. The audio world seems to have given up on latencies with buffer sizes any lower than 256/2. Certainly, most recording can be done at even higher latencies with external monitoring but the use of softsynths or software effects that require low latency monitoring from the computer is difficult at best. There is also the problem with usb devices that the latency changes every time the audio device is opened by software. The computer audio world lost when the audio device manufactures jumped from firewire to usb. Maybe (but don't hold your breath) something will change in the future. Or look for a PCIe based audio device like the audioscience cards. -- Len Ovens www.ovenwerks.net

Am 28.01.22 um 19:35 schrieb Paul Davis: Has just a new interface saw the light which I haven't heard of, yet? Sticking to the good old PCI-Clasic device, I wonder if pipewire does work well with RME HDSP. Last time I tried, I wasn't lucky. Greets! Mitsch

Am 29.01.22 um 00:34 schrieb David Kastrup: Okay, but is there already a running thunderbolt device on linux? That's the thing I wanted to hear… :) Maybe I misconfigured pw or it got confused by several tweaks I did to my system, the last time… I did a fresh debian testing install. Initializing pw should be much easier, now, with the new system.

On 1/28/22 15:05, David Kastrup wrote: I have a Dell XPS 15 with Thunderbolt 3 and a Dell Thunderbolt dock. My USB sound card is connected to the dock and shows up transparently as its usual USB self and works OOTB. I've heard that, too. I have a Presonius 12-channel Firewire device I'm planning to use on my set up the same way - TB3>TB2 adaptor. -- David W. Jones gnome(a)hawaii.rr.com authenticity, honesty, community http://dancingtreefrog.com "My password is the last 8 digits of π."

Hmm, interesting. That's the kind of problems I've got with my Focusrite 18i8. With 5.15 (and still with 5.16.2rt19), I've got an output cracking noise while there are no Xruns reported by qjackctl. If I boot on the 5.10.90rt kernel, there are absolutely no problems. Where can I report this kind of problem ? What kind of informations I can gather to help fix this problem ? Best regards, Yann Le 29/01/2022 à 10:23, Jeremy Jongepier a écrit :

On Thu, Jan 27, 2022 at 08:20:29PM -0700, Paul Davis wrote: That would be a linear interpolation of beat _duration_. The alternative is linear interpolation of beat _frequency_. The result of this will be very close to exponential, for a reasonable relative tempo change (in the range 1/2 to 2/1). Outside that range, and if the ramp takes more than a few seconds I wonder if humans will do exponential accurately enough for the difference to matter at all. -- FA

Now... this is a very, very interesting new thread... I think most software users have always 'adapted' linear tempo-changing and ramping interfaces to try and mimic somewhat 'realistic' human behaviour and indeed that can be challenging :-) What I'm wondering is: when a software offers exponential ramps etc. isn't that just a user interface? i.e. how the software then calculates the ramp values automatically for the users and sets the BPM at certain instants depending on the granularity? In that case I'd assume the software is then exposing the (calculated) BPM to e.g. plugins or a transport mechanism if it were the 'master'? I know the above depiction might technically be very naive/unaccurate, but I wonder why would plug-ins crash based on the exponential.... It's a genuine curiosity, not a loaded question btw (this is LAD after all, and always a great place to learn for me). So, I guess a quick tempo changes caused by a ramp for a BPM based plug-in, I would intuitively think might cause problems to a plug-in which is doing heavy calculations based on that BPM which is changing 'too fast', but what would the difference between a very quick linear change or even very quick random changes entered by a user and exponential ones? Lorenzo

On Fri, Jan 28, 2022 at 01:35:23PM +0100, David Kastrup wrote: I rational arithmetic is used to avoid accumulating small errors (that is the normal use case) I don't see the need for it in this context. Tempo ramps happen between begin and end points and as long as these are accurate, there will be no accumlating error. For example you could express time as integer microseconds and beats as k / N with N something like 2^8 * 3^4 * 5 * 7 which allows all common divisions of a beat to be exact with integer k [1]. The calculations that map time to beats or beats to time _within_ a tempo ramp can be safely done using floating point (as an offset from the start point) and the results rounded to the rational format. [1] And if ever you have to divide a beat by a number that doesn't divide N, there is always the Bresenhan algorithm. Ciao, -- FA

On Wed, 26 Jan 2022, Paul Davis wrote: Until pipewire supports the ffado backend, being able to run a "real" JACK is an absolute requirement. If pipewire is then to take the place of pulse, then some form of pipewire-jack bridge becomes a requirement too (for many people). The ALSA firewire modules are not even stable enough for desktop use let alone audio production. While firewire audio interfaces are no longer made, the current crop of USB devices meant to replace them, fall short. They may work just fine for recording, but for live use the stability is just not there. Beyond that, replacing a perfectly working device with another just to keep up is a problem not a solution. (like all the distros that have dropped 32 bit support) Churn is not a good thing. -- Len Ovens www.ovenwerks.net

Just try and get any help from the Jack developers and you will quickly see why Pipewire is the future. Go to Jack UG and you have to take some shampoo and Conditioner with. I contact pipewire and they are willing to listen without being snarky and evasive. If I had money to to spend on charity I would give it to pipewire. their work is badly needed so we can get out of the snobbery which jack has become. On 2022-01-26 09:29, Paul Davis wrote:

On Thu, 27 Jan 2022 02:31:21 -0500 liebrecht(a)grossmann-venter.com wrote: Very interesting to see this comment in a thread that literally includes the principal author of JACK. -- ====================================================================== Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com Without deviation from the norm, "progress" is not possible. - FZappa

Thu, 27 Jan 2022 10:59:50 -0500 - Joe Hartley &lt;jh(a)brainiac.com&gt;om>: if this is indeed the future, then I am quite right to be very concerned about the future... Regards al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! ____________________________________________________________________________ Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B

On 1/26/22 12:34 AM, Fons Adriaensen wrote: Correct, that is what I am currently doing on Fedora (which has packages that allow either the jack2 implementation of the Jack API or the Pipewire implementation to be installed). -- Fernando

"Jeanette C." &lt;julien(a)mail.upb.de&gt; writes: Frankly, in my experience the whole systemd universe (and it's not like the GNOME desktop universe is much better) is ridiculously lacking in documentation. You can do a lot with just a few lines of configuration, but there is not much of a way of arriving at those lines other than to go begging on the respective mailing lists or StackExchange. I have not evaluated Pipewire yet; but the kind of experience I am talking about is at least common for Pulseaudio in my book. Sometimes I think people might be better served if the developers documented what they are doing rather than dropping everything and developing the next hot thing. -- David Kastrup