Cable, an app to change some of Pipewire and Wireplumber settings

magillos · 2025-03-11 14:01:50

Let me share my PYQT 6 app to control some aspects of Pipewire and Wireplumber with simple side-by-side connections manager. Screenshot will likely explain what it does best:

App is available on AUR.

Project website:
https://github.com/magillos/Cable

Last edited by magillos (2025-03-11 14:07:58)

mahen · 2025-03-18 11:28:53

Hi ! That's great, exactly what I was looking for ! Thank you !

Last edited by mahen (2025-03-18 11:30:18)

magillos · 2025-03-18 11:34:14

cable --minimized

That's how app is started with auto-start on.

mahen · 2025-03-22 10:28:46

Thanks !

BTW, noticed a possible minor bug !
I set a default quantum of 64, which is saved & restored at startup.
After restarting, the value of 64 is displayed but the latency value underneath still correspond to a value of 1024 (21.33 ms instead of 1.33 ms).
When checking with pw-top, I see the actual value is actually correct, 64 buffers.

Thanks a lot

Also, sometimes, my saved value is reverted to 1024. (maybe when switching devices)
BTW, may I ask you a question ? What is the difference between setting "force-quantum" and "quantum" ?

Cheers !

Last edited by mahen (2025-03-23 09:43:54)

magillos · 2025-03-22 18:08:08

mahen wrote:

What is the difference between setting "force-quantum" and "quantum" ?

I'm guessing you're asking about how the app checks active values. It just uses pw-metadata underneath, so it has to check if the values are default (quantum) or custom (force-quantum), as shown with:

pw-metadata -n settings
Found "settings" metadata 31
update: id:0 key:'log.level' value:'2' type:''
update: id:0 key:'clock.rate' value:'48000' type:''
update: id:0 key:'clock.allowed-rates' value:'[ 48000 ]' type:''
update: id:0 key:'clock.quantum' value:'1024' type:''
update: id:0 key:'clock.min-quantum' value:'32' type:''
update: id:0 key:'clock.max-quantum' value:'2048' type:''
update: id:0 key:'clock.force-quantum' value:'0' type:''
update: id:0 key:'clock.force-rate' value:'0' type:''

And because it just uses pw-metada to set parameters, they can be over-written or not kept when devices are switched, services (wireplumber/pipewire) restarted, or they are amended with different app. Perhaps it all could be done more properly with API instead, but I haven't yet looked into that. And I definitely don't want to write into config files for permanent changes, as it could break things too easily.

I'll try to reproduce that bug you found, and if I'm able to, it should be fixed in the next version.

magillos · 2025-03-22 21:48:24

I think I fixed the bug. App wasn't refreshing values when started from tray. Updated version is now in AUR. Thanks for reporting it.

mahen · 2025-03-23 09:48:41

Thank you ! Much appreciated <3

Regarding the difference between "quantum" and "force-quantum" I was actually wondering which one it was more relevant to modify to set a custom value. My own interpretation (from a user perspective) was that a given app would use its own value or the default one depending on its behaviour if no "force-quantum" was set, but would be forced to use the "force-quantum" in the other case. So I was wondering if, in some cases, altering the default would not be safer ?

I am just making assumptions based on the name of the parameters ;-) I do appreciate the fact the Cable does not make permanent changes indeed.

Thanks for the fix ! Built !

Edit : oh, my assumption is incorrect. Even when a force-quantum is set, an app can ask for an arbitrary quantum within the limits. Firefox for instance at the very moment uses a 1764 quantum while I force a value of 64. So that's all good !

Last edited by mahen (2025-03-23 10:07:24)

magillos · 2025-03-23 10:18:24

Piepewire wiki suggests to change parameters with:

pw-metadata -n settings 0 clock.force-quantum

so this is how I would do it. I honestly don't know if there would be any practical difference if quantum was set with:

pw-metadata -n settings 0 clock.quantum

Possibly the latter is a softer setting and easier over-written by apps?

mahen · 2025-03-27 07:53:05

Yep, I kinda assume the same

Oh, BTW, any idea why the quantum is frequently, but not systematically, reverted to 1024 in Cable ? I have ticked both "save buffer and sample rate" and "autostart".

Thanks a lot !

magillos · 2025-03-27 10:19:03

I'll try to run Cable with "Save buffer" toggle on, to see if this occurs for me. So far it hasn't; custom setting survives restart, sleep cycle, plugging-in/out USB device and wireplumber service restart. Pipewire service restart would expectedly bring it back to default values so maybe monitoring it with 'journalctl -f | grep pipewire' would tell you something. Maybe pipewire is crashing for you at some point?
If it's some app changing the settings, 'pw-metadata -m' should help catching it.

But if this happens to you just at system start, maybe I could add some delay for applying custom values. There is a chance that Cable tries to apply custom buffer before pipewire is ready.

mahen · 2025-03-28 10:33:36

Hi !

Well... I'm not sure. Haven't figured out yet what triggered this yet. Will look up the journal next time it occurs.

What I can tell is that, for instance, a couple of minutes back, it reverted to 1024 just when doing the following in a loop :

- turn on the computer
- login into KDE session
- only app autostarting : Cable
- starting Arturia Piano V3 (WineASIO)

I did that a couple of times because I was testing something else. After a last restart, I noticed the sound of Piano V was all trashed because the buffer setting of the instrument did not correspond to the Pipewire value anymore.

Alternatively, would it be possible to manually save the settings or to save them only when they are manually modified ?

Thanks a lot !

magillos · 2025-03-28 12:34:41

You caught another bug. App was not refreshing to correct values of quantum and sample rate with 'Save' toggle on. It's should be fixed with 0.7.2 version (in AUR now).
I am not sure if this is going to help with your issue though. Wineasio has its own settings (you can run them with wineasio-settings), and it does not respect buffer set by Pipewire. It can be seen in pw-top. There is an option to set fixed buffer in wineasio-settings, or it can be changed in the app if it has setting for that (I don't know if Arturia allows that but most Windows apps do).

Alternatively, would it be possible to manually save the settings or to save them only when they are manually modified ?

Custom settings are only saved (written to ~/home/.config/cable/config.ini file) when 'Save' toggle is on and 'Apply' button is hit. Unchecking 'Save' toggle or hitting reset buttons clears them.

Thanks again for testing!

mahen · 2025-03-28 14:20:16

Thanks for the fix !

No issues, my problem is fixed, as I am now sure my wineasio & PW settings are not altered. Thanks !

Last edited by mahen (2025-03-28 16:27:30)

mahen · 2025-04-01 08:33:02

Oh, you are bringing very cool new features to Cables ! (latency test just now) Thanks !

Still seeing my quantum being reverted to 1024, hmm... Maybe it also occurs after updates ? I have to investigate some more.

magillos · 2025-04-01 16:59:57

You are right. There was an issues with the app that I hopefully fixed. (It was the "save" toggle that was was triggering writing to config file at start). I have no idea why I didn't catch it. I also removed saving values on app window close. I don't even remember why I added it in the first place, as it didn't make much sense.

I'm also trying to add some small features to connections manager, so not sure yet when will I push it to GitHub. If I struggle too much with this, I'll just upload bug fix release.

Thanks for testing it!

Edit: I pushed 0.9.1 version to AUR. Let me know if you still have issues with it.

Last edited by magillos (2025-04-01 17:21:28)

jebez · 2025-04-11 13:06:44

It already exists https://archlinux.org/packages/extra/x86_64/qpwgraph/ ...

magillos · 2025-04-11 15:10:11

I'm not sure what your point is.

mahen · 2025-05-18 10:12:10

Checking once in a while... Cable is getting better & better. Great work !

mahen · 2025-07-27 10:54:49

@magillos : Hi

I was surprised to see I could halve the latency in my Arturia instruments (through Wine & Wineasio), Pianoteq etc. by raising my sound card rate to 96 KHz (and keep the same number of buffers, while halving the buffers would lead to "xruns").

I wonder if it is possible to switch from 16 bits to 24 bits ? My sound card supposedly supports 24 bits & 192 KHz (my Arturia instruments only support 96 KHz).

I still find a tiny bit of latency when using 128 buffers & 96 KHz. This is very subtle, but as a piano player, I still notice it and it reduces a bit the pleasure of playing (as far as I'm concerned).

Thanks a lot !

magillos · 2025-07-27 17:55:31

Have you tried 96/96kHz? See here for optimal values: https://wiki.linuxaudio.org/wiki/list_o … _interface (As far as I understand it, Pipewire uses 2 periods and that can't be changed as with Jack).

I get good results with 48/48kHz, while 64/48kHz is unusable due to xruns, but it could be my sound card specifics. 96/96kHz would give you nice 2ms latency (possibly the lowest achievable value), which should translate to around 6-7ms round-trip. You can now actually measure that in Cable.

Bit depth won't impact your latency.

mahen · 2025-09-05 08:07:33

Hi ! Coming back after a few weeks of tests ;-)

Still trying to figure out the optimal settings for the lowest possible latency... I (finally) took the time to use the "latency test" tool and it was massively useful.

Using : PW 1.4.x, Arch, a 10 year-old i5 (i8600K, 6 cores), and an affordable Yamaha USB AG06 sound card.

First I looked for a setting that would not trigger xruns / micro-cuts for my Arturia instruments (Analog Lab) through Wine/WineASIO, for BitWig, and Pianoteq.

96KHz is optimal. (cuts latency in half and does not add xruns - 192 is unsupported by Arturia instruments and slower in Bitwig)
Quantum : 64 for light instruments like regular pianos up to 256 for heavier ones like Pigments, Augmented piano... and multitracking in Bitwig.
So, I thought I would settle with a quantum of 256. It was OK for playing the piano (slight latency but OK) and the heaviest Pigments patches would generally not cut.
(I don't want to switch constantly !!)

Then I tried latency test. Here are my findings :

1) no difference at all when using different USB ports
2) 96 KHz is indeed optimal (slightly better latency than 48 KHz with half quantum) (slightly worse than 192 KH z with double quantum)
3) the round-trip latency is massively higher than twice the indicated latency
4) pro-audio mode makes a HUGE difference
5) BUT I get more cuts / xruns in pro-audio mode with the same quantum value (I have to double it)

Q 64, R 96, L 0.67 ms
Round-trip : 8.660 ms
Pro audio round-trip : 3.443 ms

Q 128, R 96, L 1.33 ms
Round-trip : 14.749 ms
Pro audio round-trip : 4.784 ms

Q 256, R 96, L 2.67 ms
Round-trip : 25.427 ms
Pro audio round-trip : 7.430 ms

Q 512, R 96, L 5.33 ms
Round-trip : 30.833 ms
Pro audio round-trip : 12.659 ms

Q 1024, R 96, L 10.67 ms
Round-trip : 47.343 ms
Pro audio round-trip : 23.451 ms

Conclusion : to get the same "uncut audio in all conditions" in pro audio mode, I have to use a quantum of 512. That gives a round trip latency of 12.7 ms in pro audio mode, which is way better than my former setting of 256 in non-pro mode (25.5 ms).

If I want to focus on piano playing, I could use a smaller quantum & Pianoteq and obtain a ridiculously low latency (yeehaw !). If I want to focus on music production I could raise it...

I guess there are drawbacks in using this "pro audio" mode ?
I really wonder to what extent I could improve the situation by : upgrading the cpu, changing my audio interface, switch to jack, etc etc. I'm at least gonna try a realtime kernel -- which did not make a different in non-pro mode before.

Edit : I tried to switch to an RT kernel. Not better. Worse actually. Get crackling in pianoteq I didn't have before. And the round-trip is the same.

Edit 2 : I finally settled with Q 512, R 96, L 5.33, pro round-trip 12.7 ms. No crackling at all. Pretty low DSP load in bitwig. Not sure I can actually perceive the latency. When I lower the quantum value, there are a few cases here & there I get slight crackling -- even in Pianoteq. It really is pretty satisfying, as I am using a pretty old PC and pretty great instruments (Pianoteq & Arturia Analog Lab).

I heard somewhere an ideal round-trip latency was below 10 and a good one below 20 ms.

Last edited by mahen (2025-09-05 19:42:19)

mahen · 2025-09-05 20:06:39

So, in conclusion, I could eventually get a pretty satisfying experience (with both 96 KHz & pro mode set).
Still, I need to set a quantum of 512, which is really high compared to what I used to experiment before (for an adequate 12 ms round trip latency).

I kinda remember I used to use Pianoteq with only a 32 or 64 buffers jack configuration (in 48 KHz... 2 or 3 periods ?), with a similar computer a few years back. (but with Jack & a PCI soundcard I think). I had made no latency measure though.

Last edited by mahen (2025-09-05 20:07:01)

magillos · 2025-09-09 10:24:24

Are you using https://github.com/rncbc/rtirq? Also, check out https://codeberg.org/rtcqs/rtcqs for other tweaks.

mahen · 2025-09-09 11:40:24

Yep, did all that !
I really only get an xrun once in a while when dividing by 2 my quantum. So close ! (enough to be distracting)

Out of curiosity, I tried to live boot from a music production oriented distro and tried the Pianoteq demo. I could set the minimum values (& a higher rate !) with no crackling. But that was in "direct alsa" mode. So there is definitely some room for improvement.

I don't have the courage right now to try and wipe Pipewire from my installation, or to make a proper dual boot !

(well, 12.5 ms round-trip is already good enough - 8.5 ms would've been a dream. But, let's see what happens in further PW releases !)

Last edited by mahen (2025-09-09 12:08:44)

magillos · 2025-09-09 12:54:16

magillos wrote:

Are you using https://github.com/rncbc/rtirq? Also, check out https://codeberg.org/rtcqs/rtcqs for other tweaks.

ALSA will perform best (no overhead) but it's the least convenient out of 3. No need to wipe out Pipewire if you want to try ALSA. Just select it in your app but you will only be able to use that one app only as ALSA will lock audio device.

If you want to try JACK instead of pipewire-jack just install jack2 package. You can also try installing pipewire-jack-client afterwards to make all Pipewire clients connect through JACK. In that case, use Qjackctl instead of Cable and for pipewire-jack-client to work enable Jack D-bus in Qjackctl.
You will encounter broken dependencies errors so you'll need to use 'pacman -Sdd'. To revert, install pipewire-jack.

For sanity check, have a look at "iotop -ao" if you haven't got any disk activities potentially causing xruns.

Arch Linux

#1 2025-03-11 14:01:50

Cable, an app to change some of Pipewire and Wireplumber settings

#2 2025-03-18 11:28:53

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#3 2025-03-18 11:34:14

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#4 2025-03-22 10:28:46

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#5 2025-03-22 18:08:08

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#6 2025-03-22 21:48:24

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#7 2025-03-23 09:48:41

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#8 2025-03-23 10:18:24

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#9 2025-03-27 07:53:05

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#10 2025-03-27 10:19:03

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#11 2025-03-28 10:33:36

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#12 2025-03-28 12:34:41

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#13 2025-03-28 14:20:16

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#14 2025-04-01 08:33:02

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#15 2025-04-01 16:59:57

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#16 2025-04-11 13:06:44

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#17 2025-04-11 15:10:11

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#18 2025-05-18 10:12:10

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#19 2025-07-27 10:54:49

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#20 2025-07-27 17:55:31

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#21 2025-09-05 08:07:33

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#22 2025-09-05 20:06:39

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#23 2025-09-09 10:24:24

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#24 2025-09-09 11:40:24

Re: Cable, an app to change some of Pipewire and Wireplumber settings

#25 2025-09-09 12:54:16

Re: Cable, an app to change some of Pipewire and Wireplumber settings

Board footer