Continuing the jack/pipewire debate...

[All in One Wish]

Let's say your Distro comes with PipeWire in a good solid recent version, you are new to Linux and you want to try Ardour but your stems to import are all at 44.1Khz.. PipeWire's default is 48000Khz and Ardour is either going to blunt force convert the sample rate on import or it's going to accommodate on the fly which is a worse option so if you just want to get the system running at 44100Khz you're going to either have to bang open a terminal and incant some pipewire-metadata command which as a newbie you will neither want to open a terminal nor will probably have no idea what command to enter. Other than that unless your Distro ships a PipeWire metadata GUI (most don't yet) you're going to have to go into the system file tree with a text editor and then tell PipeWire you want 44100Khz in one of many obtusely named config files..

You brought up a really good point with that scenario, and it's one I hadn't yet encountered. Out of the box, it is indeed a giant pain to change sampling rates in PW. I started and Ardour session, selected JACK as my backend (which is really PW, since this system has never had real JACK installed), and it was locked to 48 kHz.
So looked around and found a simple graphical utility. With the 48 kHz Ardour session still running, I used the GUI I had downloaded to set the sampling rate to 44.1. Ardour complained that the sampling rate had changed during an open session, but it recognized and locked to the new rate.
So tools like this do already exist, but I'll admit that it is a problem that they're not shipping with standard distros or PW itself. This, I suspect, will change.

You've mentioned some front ends and different GUI's for pipewire. Can you make a list and maybe a link to the binaries for debian? (Maybe add some brief notes on features/pros/cons?

Pipewire came by default on my MX Linux 21 Wildflower box, I didn't do AVL this time because (*)I wanted to try pipewire. I went through a trillion settings I've read here to be applied on config files to adjust latency and nothing worked to lower it on my firewire RME fireface 800. So I uninstalled pipewire and totally abandoned that one machine since then due to my work schedule. Now pipewire it's going through .83 and I'd like to reinstall to see if anything has changed that would reduce my latency. I couldn't even play a keyboard or a guitar.

(*) I truly like the promise of pipewire and I'm bidding for its success even though it's in its earlier stages of development. Back in 2008 I used to set up computers for audio (at the time on windows) for my students and once a student brought a white 2006 macbook (it's all she had). I couldn't believe the features on this 1.83 mhz 2 gb of ram laptop. It ran on Snow Leopard and garage band would recognize my adding/removing USB keyboards on the fly and there was no latency I could notice when playing a keyboard and not discernible latency and great effect presets when plaiying guitar and my student could play a youtube video or a song on iTunes to play along and recording had automatic latency compensation. So, I thought, it's 2023, I'm using an i9 box with 128gb of ram and an SSD and... Oh well... That being said, I think no one has made it a goal in Linux to reach Apple's 2008's Coreadio simplicity and performance until now that pipewire is working on this. I totally hope it succeeds. I do get that for many, Jack does what it needs to do in their systems and respect the attitude behind "what's working should be left alone", but what matter here is the goals and my thought is that we should make as much noise as possible for it to also deliver for us as pipewire is getting adopted by several distributions. We need as much lobbying in the pipewire congress as possible so our real time audio priorities are pondered.

I love Linux and use it every day but I want to switch to my right side of the brain when I'm making music and let intuition do its thing. Music will typically sound too structured if it lacks the whimsy and is overpowered by intellectual workout.
Normally people who are too predominant on their left side of the brain would have to do like yoga to put all that aside and let their senses take over. All this config work is exactly the opposite. Maybe Johann Sebastian Bach could keep beauty and intellect neck and neck but I'm just a normal dude who would like to take advantage of inspiration when it hits.

Things that worked with Pipewire for me that wouldn't work with Jack:
Pipewire allowed me to play any DAW through HDMI. Why? Because if I simply wanted to listen to something I've done I wouldn't have to get behind my Yamaha's HS8s and bother my neighbor downstairs Jack would not play through HDMI no matter what I did. Pipewire allowed this out of the box.
Things I expected from Pipewire that didn't work as expected:
Latency was abismal though and configuration procedures to make latency changes were more complex than with Jack.
I was unable to figure out the supposed to be pipewire ZEROCONFIG module that's supposed to be included in pipewire to recognize my Apple Airport express devices which I can use to play music through an iMac I have in the kitchen with Snow Leopard, 1GB of ram and a 1.83 Ghz processor which cost me 12 bucks and works great as a wireless printer server. Apparently such module is not available in the installs that are available on MX-Linux.

Regards!

[glowrak guy]

Just don't use it if you don't want to?

I actually want to be able to recommend things to people, that will improve their situation.
Whether I use it, or not. Extra work without superior results, and change for the sake of change,
or an ego-driven 'trust me, my creation is better' simply isn't good enough for me.
It may be fine for many, and it's a work in progress worth watching from a safe distance.
Cheers

[sysrqer]

Just don't use it if you don't want to?

I actually want to be able to recommend things to people, that will improve their situation.
Whether I use it, or not. Extra work without superior results, and change for the sake of change,
or an ego-driven 'trust me, my creation is better' simply isn't good enough for me.
It may be fine for many, and it's a work in progress worth watching from a safe distance.
Cheers

Don't recommend it then?

[erlkönig]

Do you worry about the software stack of your wifi adapter?

...beside the fact that you never would do audio via wlan (what you didn't state, i know it was an example for hiding complexity), when you need reliability: if you are on the road with AES67 or Dante, you're in the game with your stack, especially the layers they're working on.
If there was really an outshining feature of a superior soundserver, than it would be AES67 capabilities.

[Impostor]

linux audio is currently even more obscure than before, imo.

Case in point:

viewtopic.php?p=161676#p161676

[matyas]

Do you worry about the software stack of your wifi adapter?

...beside the fact that you never would do audio via wlan (what you didn't state, i know it was an example for hiding complexity), when you need reliability: if you are on the road with AES67 or Dante, you're in the game with your stack, especially the layers they're working on.
If there was really an outshining feature of a superior soundserver, than it would be AES67 capabilities.

While I would love to run AES67 or Dante under Linux, I wasn't referring to audio specifically with that comment and I apologize if it caused any confusion.

To clarify: in general, networking on Linux basically just works, at least at the desktop/consumer level. Turn on wifi or connect ethernet cable, enable dhcp or set ip address, and you're in business. There is a whole lot happening behind the scenes that you can mostly ignore unless you're a network engineer. This has not always been the case. One upon a time, wifi on Linux could involve messing around with a whole lot of cumbersome files and utilities. A lot of changes to the networking stack have taken place over the years, and people by and large do not complain about them.

I want Linux audio to be as simple and effortless as Linux networking. Yes, people are used to messing around with JACK and ALSA and PulseAudio and custom kernels and real-time permissions and all of that. And people who come from Windows basically accept that because the situation on Windows is arguably worse.

It doesn't have to be that way. Pipewire is 90% of the way there, already. As I keep repeating, my current system has the best performance of any Linux or Windows audio machine I've ever set up, and I did the least amount of tweaking.

[matyas]

linux audio is currently even more obscure than before, imo.

Case in point:

viewtopic.php?p=161676#p161676

That's just a case of old documentation still floating around. Install QPWGraph instead of Qjackctl. Problem solved. Ardour works great with PW-Jack.

[tseaver]

@matyas

That's just a case of old documentation still floating around. Install QPWGraph instead of Qjackctl. Problem solved. Ardour works great with PW-Jack.

qpwgraph doesn't handle all the usecases that qjackctl does: it only provides the patchbay bits. I don't think there is a widely-accepted PW GUI tool for doing things like:

• changing the sample rate for all JACK clients (so that they don't waste cycles up-and-down-sampling all over the place);
• starting / stopping / seeking the JACK transport;
• starting clients (the "Session" button in qjackctl), versus configuring their connections (I don't use this bit myself).

[erlkönig]

@matyas

I wasn't referring to audio specifically with that comment and I apologize if it caused any confusion.

...i think i got you right, i was not confused and you have no reason to apologize

For staying with your example: you can't always hide complexity: AES67 and Dante both work on Layer3, which means: if they are running via a switch with an mtu set too low or two high, your audio will be broken, and you won't get any message about this. That's not a fault. It's part of the design and you have to know about this, when you are running these techniques in a professional environment. So if anything goes wrong, e.g. when in a small radiostation the same network is used for AES67 and the rest (shares on a network, VoIP, ect) you will have to be familiar with the stack (OSI Layers) to know what screws to turn (in your hopefully managed switch). What works at home easily, does not necessarily work outside.
But that's now completely off topic.

If pw runs for you easily: fine, use it .

[matyas]

@matyas

That's just a case of old documentation still floating around. Install QPWGraph instead of Qjackctl. Problem solved. Ardour works great with PW-Jack.

qpwgraph doesn't handle all the usecases that qjackctl does: it only provides the patchbay bits. I don't think there is a widely-accepted PW GUI tool for doing things like:

• changing the sample rate for all JACK clients (so that they don't waste cycles up-and-down-sampling all over the place);
• starting / stopping / seeking the JACK transport;
• starting clients (the "Session" button in qjackctl), versus configuring their connections (I don't use this bit myself).

Agreed that this is one area where PW admittedly needs some work. There are a few utilities floating around, but nothing included in standard distros. I'm using this: https://github.com/cyber-sushi/pipewire ... ate-config
But admittedly, as a Python script, rather than a complied app with an easy installer, it's probably harder to use for most people.

[revoxs]

Re: pipewire gui's: See viewtopic.php?p=160196#p160196

[Audiojunkie]

I haven't tried this one yet, but it looks like you can change all sorts of low level settings with this GUI. Maybe this will work for some of you?

https://github.com/dimtpap/coppwr

[Largos]

I don't know whether the people that make these config utilities are misunderstanding some things (or maybe I am). They either use force or max/min settings when I think they should be using the default settings. For instance, I have pipe control, I load the computer and the settings in pipe control are the following.

Force Sample Rate: Do Not Force.
Min Buffer: 32
Max Buffer: 2048
Force Buffer Size: Do Not Force

I boot Carla and it (I presume all current JACK programs do also) uses the value of "default.clock.quantum" in the config file and connects at 1024. If I want to reduce the quantum/buffer with Pipe Control, I need to change put max buffer to as low as I want it or use Force Buffer. This, however, means I could not use a higher/different buffer with other programs which is a feature.

[tjarx]

I'm afraid it's not possible to set per-application latency on the fly using pipewire. At least it is not mentioned here:

https://gitlab.freedesktop.org/pipewire ... plications

You can configure latency on an application level via config files. I have not tested whether these settings could come into effect by simply reconnecting your application to the jack/pipewire backend. The other way to specify an application's latency is to set the environment variable PIPEWIRE_LATENCY before starting it.

[erlkönig]

...just for my understanding: pw sets latency on a client base?