13 Aug
2024
13 Aug
'24
3:39 p.m.
Hello all,
I spent a lot a time reading whatever docs I could find for Pipewire,
and discuss things with some users, only to get frustrated more and
more.
Below is a description of the configuration I'd want. If anyone knows
how to do this (it shouldn't be that difficult) that person will
receive my eternal admiration and gratitude.
1. Jack2 and some clients are started manually after I login,
and will be running all the time.
2. Currently the ALSA Jack plugin is used to route audio from
web browsers etc. to Jack. PW may take over this role but
that is not a strict requirement.
3. PW will be started manually when required, and I don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.
4. All Jack ports created by PW should be permanent and exist
as soon as PW is started, so they can be manually connected
and remain connected even when not in active use.
5. PW should never ever access the sound card used by Jack,
not even if accidentally started when Jack is not running.
It must not force Jack to use dbus in order to get access
to that card. It may manage other sound cards, but preferably
only those explicitly listed.
6. PW must never ever interfere with Jack in any way - making
connections, trying to change the period size, etc. Its only
role is to be a well-behaved Jack client.
7. I do not expect anything 'automatic' to happen when things
are plugged in or out.
8. The PW configuration should be done in such a way such that
it can't be modified by drop-in files from the system package
manager. All configuration should be manual and explicit, and
easy to verify without having to scan a myriad of files and/or
directories and trying to understand how they interact. This
is just basic security.
Ciao,
--
FA
13 Aug
13 Aug
5:36 p.m.
Hi Fons,
As far as I know pipewire can not currently meet all 8 of your
requirements, but I best leave this to Wim to answer.
On 2024-08-13 15:39, Fons Adriaensen wrote:
1. Jack2 and some clients are started manually after I
login,
So you finally made the switch to jack2?
and will be running all the time.
just a sidenote. doing that killed the battery on my old laptop.
3. PW will be started manually when required, and I
don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.
I do occasionally run pipewire, and do so from its source tree by just
calling `make run`.
Then I use the following script to launch applications that i want to
test with pipewire:
```
#!/bin/bash
PW_SRC=$HOME/src/pipewire/
export SPA_PLUGIN_DIR=$PW_SRC/builddir/spa/plugins
export SPA_DATA_DIR=$PW_SRC/spa/plugins
export PIPEWIRE_MODULE_DIR=$PW_SRC/builddir/src/modules
export PIPEWIRE_CONFIG_DIR=$PW_SRC/builddir/src/daemon
export ACP_PATHS_DIR=$PW_SRC/spa/plugins/alsa/mixer/paths
export ACP_PROFILES_DIR=$PW_SRC/spa/plugins/alsa/mixer/profile-sets
export LD_LIBRARY_PATH=$PW_SRC/builddir/pipewire-jack/src/
export
PATH=$PW_SRC/builddir/pipewire-jack/src/:$PW_SRC/builddir/src/tools:$PATH
exec "$@"
```
e.g pw-src-env pw-jack Ardour8
The downside compared to using the JACK/ALSA bridge is that a already
running applications will not connect to pipewire after the fact.
Maybe you already knew this, if not I'll take 1/8th of your eternal
admiration and gratitude :)
4. All Jack ports created by PW should be permanent
and exist
as soon as PW is started, so they can be manually connected
and remain connected even when not in active use.
[...]
7. I do not expect anything 'automatic' to
happen when things
are plugged in or out.
This is something where macOS' Coreaudio/MIDI shines. Unlike macOS
Linux/ALSA has no persistent unique IDs for soundcards or MIDI devices.
ALSA supports hotplug, and first come first server sequential numeric
IDs. The best you^Wpipewire can do is keep track of cards by name.
So this is not something pipewire can reliably address, until ALSA get
support to identify cards by vendor and serial-number, and provide a UUID.
Cheers!
robin
7:06 p.m.
Le 2024-08-13 à 11 h 36, Robin Gareus a écrit :
This is something where macOS' Coreaudio/MIDI
shines. Unlike macOS
Linux/ALSA has no persistent unique IDs for soundcards or MIDI
devices. ALSA supports hotplug, and first come first server sequential
numeric IDs. The best you^Wpipewire can do is keep track of cards by
name.
So this is not something pipewire can reliably address, until ALSA get
support to identify cards by vendor and serial-number, and provide a
UUID.
I use a variation of this udev rule to assign names for my sound devices:
https://gist.githubusercontent.com/mpaolino/91c3587045fa8d1a9353b74bf102c83…
Marc
8:42 p.m.
On Tue, Aug 13, 2024 at 05:36:08PM +0200, Robin Gareus wrote:
So you finally made the switch to jack2?
Jack1 is still occasionally running clients in the wrong
order, and while that may not affect most users it is a
real PITA for me. If such a fundamental problem still isn't
resolved more than 10 years after it was first reported
that doesn't inspire trust. Apart from that, Archlinux
moved Jack1 to the AUR, so there's no binary package for
it anymore.
Then I use the following script to launch applications
that i want to test
with pipewire:
```
#!/bin/bash
PW_SRC=$HOME/src/pipewire/
export SPA_PLUGIN_DIR=$PW_SRC/builddir/spa/plugins
export SPA_DATA_DIR=$PW_SRC/spa/plugins
export PIPEWIRE_MODULE_DIR=$PW_SRC/builddir/src/modules
export PIPEWIRE_CONFIG_DIR=$PW_SRC/builddir/src/daemon
export ACP_PATHS_DIR=$PW_SRC/spa/plugins/alsa/mixer/paths
export ACP_PROFILES_DIR=$PW_SRC/spa/plugins/alsa/mixer/profile-sets
export LD_LIBRARY_PATH=$PW_SRC/builddir/pipewire-jack/src/
export
PATH=$PW_SRC/builddir/pipewire-jack/src/:$PW_SRC/builddir/src/tools:$PATH
exec "$@"
```
e.g pw-src-env pw-jack Ardour8
All that to just run one application ?
And isn't this using PW as a Jack emulation ? That is not what I want
to do. All Jack apps should just use Jack. PW is there only for those
that for whatever reason do no support Jack natively - most browsers,
video conference apps, etc.
> 7. I do not expect anything 'automatic'
to happen when things
> are plugged in or out.
This is something where macOS' Coreaudio/MIDI
shines. Unlike macOS
Linux/ALSA has no persistent unique IDs for soundcards or MIDI devices. ALSA
supports hotplug, and first come first server sequential numeric IDs. The
best you^Wpipewire can do is keep track of cards by name.
So this is not something pipewire can reliably
address, until ALSA get
support to identify cards by vendor and serial-number, and provide a UUID.
You may have misunderstood (7). If the hardware changes I have no
problem with having to modify the config and restart everything.
All I meant is that I'm not interested in having the entire system
automagically switching to another sound card when some USB device
is plugged in or out, or anything similar.
Ciao,
--
FA
14 Aug
14 Aug
1:12 a.m.
On Tue, 13 Aug 2024, Robin Gareus wrote:
This is something where macOS' Coreaudio/MIDI
shines. Unlike macOS Linux/ALSA
has no persistent unique IDs for soundcards or MIDI devices. ALSA supports
hotplug, and first come first server sequential numeric IDs. The best
you^Wpipewire can do is keep track of cards by name.
So this is not something pipewire can reliably address, until ALSA get
support to identify cards by vendor and serial-number, and provide a UUID.
It would of course help if device venders actually added a serial number
other than 0. I found the best I could do was manufacture:model and then
find out which physical usb port the device was plugged into. The bus:port
shown by ALSA changes just by unplugging and replugging using the same
port. ALSA also does not list the serial number even if it is something
other than 0. As with the physical port, one has to do a dance through the
USB info to find that out.
Having said that, it makes me wonder how Coreaudio can distinguish between
two USB mics if they don't have serial numbers. USB mics being
particularily bad for not having serial nummbers while at the same time
being something that gets used in twos and threes for pod casts. (yes,
requiring SRC to work but both coreaudio and pipewire handle that part
without saying anything)
Len
--
Len Ovens
www.ovenwerks.net
13 Aug
13 Aug
10:11 p.m.
PW always start at login. This is annoying...
But it can be be disabled at login using this script:
#!/bin/sh
systemctl --user stop pipewire.socket pipewire-pulse.socket
pipewire-pulse.service pipewire.service
systemctl --user disable pipewire.socket pipewire-pulse.socket
pipewire-pulse.service pipewire.service
Then to start PW manually, another script:
#!/bin/sh
systemctl --user start pipewire.socket pipewire-pulse.socket
pipewire-pulse.service pipewire.service
If jack already use a sound device, PW won't use this busy sound device.
For PW on Jack:
https://wiki.archlinux.org/title/PipeWire#Run_PipeWire_on_top_of_native_JACK
(I did not try, but it looks similar to the pulseaudio bridge).
Marc
Le 2024-08-13 à 09 h 39, Fons Adriaensen a écrit :
Hello all,
I spent a lot a time reading whatever docs I could find for Pipewire,
and discuss things with some users, only to get frustrated more and
more.
Below is a description of the configuration I'd want. If anyone knows
how to do this (it shouldn't be that difficult) that person will
receive my eternal admiration and gratitude.
1. Jack2 and some clients are started manually after I login,
and will be running all the time.
2. Currently the ALSA Jack plugin is used to route audio from
web browsers etc. to Jack. PW may take over this role but
that is not a strict requirement.
3. PW will be started manually when required, and I don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.
4. All Jack ports created by PW should be permanent and exist
as soon as PW is started, so they can be manually connected
and remain connected even when not in active use.
5. PW should never ever access the sound card used by Jack,
not even if accidentally started when Jack is not running.
It must not force Jack to use dbus in order to get access
to that card. It may manage other sound cards, but preferably
only those explicitly listed.
6. PW must never ever interfere with Jack in any way - making
connections, trying to change the period size, etc. Its only
role is to be a well-behaved Jack client.
7. I do not expect anything 'automatic' to happen when things
are plugged in or out.
8. The PW configuration should be done in such a way such that
it can't be modified by drop-in files from the system package
manager. All configuration should be manual and explicit, and
easy to verify without having to scan a myriad of files and/or
directories and trying to understand how they interact. This
is just basic security.
Ciao,
15 Aug
15 Aug
2:28 a.m.
Le 2024-08-13 à 16 h 11, Marc Lavallée a écrit :
For PW on Jack:
https://wiki.archlinux.org/title/PipeWire#Run_PipeWire_on_top_of_native_JACK
(I did not try, but it looks similar to the pulseaudio bridge).
I tried and it works, but I had to upgrade Pipewire to a recent version;
I use Debian stable so I backported Pipewire from the unstable packages.
My lazy way to ensure than Pipewire always use Jackd for input and
output I disable the Pipewire profiles of all devices (using the
pavucontrol gui).
Jackd must be started with jackdbus (I use QJackCtl).
Marc
11:02 a.m.
On Wed, Aug 14, 2024 at 08:28:06PM -0400, Marc Lavallée wrote:
I tried and it works, but I had to upgrade Pipewire to a recent version;
I tried this:
- Copied pipewire.conf to ~/.config/pipewire
- Removed the jack-dbusdetect module from context.modules
- Added the jack-tunnel module to context.modules with 2 channels
in each direction.
Jack is running with the dbus interface disabled.
Rationale: I don't want any apps to control Jack, and dbus
is not needed to become a Jack client.
- Start pipewire
- Jack Source and Jack Sink nodes are shown in the coppwr
'graph' window, with state = Running.
But no pipewire ports are shown in the Qjackctl connections
window. The 'Info' tabs in coppwr say Input Ports = 0 and
Output Ports = 0, even if the modules or configured for 2
channels each.
No idea what to do next.
--
FA
3:43 p.m.
Le 2024-08-15 à 05 h 02, Fons Adriaensen a écrit :
Jack is running with the dbus interface disabled.
Rationale: I don't want any apps to control Jack, and dbus
is not needed to become a Jack client.
A Jack client named Pipewire with capture and playback ports shows in
the graph window of QJackCtl.
And jack_lsp is reporting:
PipeWire:playback_FL
PipeWire:playback_FR
PipeWire:playback_0
PipeWire:capture_FL
PipeWire:capture_FR
PipeWire:capture_0
Output of the pw-dump command have many related config variables (or
states); maybe you can use this information to craft a config that would
not require jackdbus, so I suggest to enable jackdbus in order to better
investigate.
Looking at the source, jackdbus is used to manage a pipewire sink/source:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/modules/…
And also to inform the jack-tunnel module with parameters:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/modules/…
It looks like the parameters can also be provided by the pipewire config.
Marc
5:31 p.m.
Le 2024-08-15 à 09 h 43, Marc Lavallée a écrit :
It looks like the parameters can also be provided by
the pipewire config.
Indeed, it seems to work.
I made a copy of the pipewire config (~/.config/pipewire/pipewire.conf)
I disabled dbus and added autoloading of the jack-tunnel module:
support.dbus = false
module.jackdbus-detect = false
module.jack-tunnel = true
I added a config file: ~/.config/pipewire/pipewire.conf.d/jack-tunnel.conf
Its content is based on what is in the source code of the module:
context.modules = [
{ name = libpipewire-module-jack-tunnel
args = {
#jack.library = libjack.so.0
#jack.server = null
jack.client-name = MyPipeWireTunnel
#jack.connect = true
#tunnel.mode = duplex
#midi.ports = 0
#audio.channels = 2
#audio.position = [ FL FR ]
source.props = {
# extra sink properties
}
sink.props = {
# extra sink properties
}
}
}
]
So I only changed the client name to see if my custom config is being used.
Then I restarted pipewire. The jack sinks are present in pipewire, and
also the pipewire jack clients. With 2 channels (stereo).
jack_lsp is reporting:
MyPipeWireTunnel:playback_FL
MyPipeWireTunnel:playback_FR
MyPipeWireTunnel:playback_0
MyPipeWireTunnel:capture_FL
MyPipeWireTunnel:capture_FR
MyPipeWireTunnel:capture_0
The jack server was started automatically by pipewire, even if I
disabled jackdbus in /usr/share/dbus-1/services/org.jackaudio.service (I
commented out the last line: # Exec=/usr/bin/jackdbus auto)
Pipewire used ~/.jackdrc to start jackd. If this file is not present,
pipewire don't work, so there's now a dependency between pipewire and
jack; pipewire is actually waiting for a ~/.jackdrc file, so once it's
created by QJackCtl, pipewire starts.
I hope it helps!
Marc
16 Aug
16 Aug
6:50 a.m.
On Thu, 15 Aug 2024, Marc Lavallée wrote:
I made a copy of the pipewire config
(~/.config/pipewire/pipewire.conf)
I disabled dbus and added autoloading of the jack-tunnel module:
support.dbus = false
module.jackdbus-detect = false
module.jack-tunnel = true
Ok
I added a config file: ~/.config/pipewire/pipewire.conf.d/jack-tunnel.conf
Its content is based on what is in the source code of the module:
context.modules = [
{ name = libpipewire-module-jack-tunnel
args = {
#jack.library = libjack.so.0
#jack.server = null
jack.client-name = MyPipeWireTunnel
#jack.connect = true
#tunnel.mode = duplex
#midi.ports = 0
#audio.channels = 2
#audio.position = [ FL FR ]
source.props = {
# extra sink properties
}
sink.props = {
# extra sink properties
}
}
}
]
I notice both midi.ports and audio.channels are commented out is that why
there are three ports in each direction? WHat does jack.lsp -t say about:
MyPipeWireTunnel:playback_0
MyPipeWireTunnel:capture_0
Are they audio or midi?
Anyway looks good. Time to start playing with PW again.
Then I restarted pipewire. The jack sinks are present
in pipewire, and also
the pipewire jack clients. With 2 channels (stereo).
Does this mean they show up on the jackd graph or just the pw jack graph?
I guess I want all three: pw as pulse, pw_jack and jackd... though
actually the pw_jack graph is of little interest if pw_pulse shows the
jackd ports for now. I suppose at some point some desktop apps may choose
to interface direct to PW_jack.
jack_lsp is reporting:
MyPipeWireTunnel:playback_FL
MyPipeWireTunnel:playback_FR
MyPipeWireTunnel:playback_0
MyPipeWireTunnel:capture_FL
MyPipeWireTunnel:capture_FR
MyPipeWireTunnel:capture_0
The jack server was started automatically by pipewire, even if I disabled
jackdbus in /usr/share/dbus-1/services/org.jackaudio.service (I commented out
the last line: # Exec=/usr/bin/jackdbus auto)
Pipewire used ~/.jackdrc to start jackd. If this file is not present,
pipewire don't work, so there's now a
dependency between pipewire and
jack;
pipewire is actually waiting for a ~/.jackdrc file, so
once it's created by
QJackCtl, pipewire starts.
Good to know. One more question: can you start more than one jack tunnel?
Say one for midi and one for audio? More than one audio?
--
Len Ovens
www.ovenwerks.net
3:41 p.m.
Le 2024-08-16 à 00 h 50, Len Ovens a écrit :
Note that once a ~/.jackdrc is present, and if all is closed, restarting
pipewire takes care of restarting jackd. If jackd is then stopped,
pipewire don't restart jackd, and if jacks is restarted manually (or
using QJackCtl), the tunnel does not reappear. That's probably why using
jackdbus is a "better" option.
I notice both midi.ports and audio.channels are
commented out is that
why there are three ports in each direction?
My understanding is that lines that are commented out in configs
(provided by pipewire) is a form of inline documentation with default
values.
WHat does jack.lsp -t say about:
MyPipeWireTunnel:playback_0
MyPipeWireTunnel:capture_0
Are they audio or midi?
8 bit raw midi
Does this mean they show up on the jackd graph or just
the pw jack graph?
Yes.
pipewire is
actually waiting for a ~/.jackdrc file, so once it's
created by QJackCtl, pipewire starts.
Good to know. One more question: can you start more than one jack
tunnel? Say one
for midi and one for audio? More than one audio?
I don't known, but It's possible to add more audio channels if using
defined audio positions (which mean that 64 channels need to have a set
of 64 defined audio positions). I was unable to add more midi channels.
Maybe jackdbus is required...
Marc
10:03 a.m.
On Thu, Aug 15, 2024 at 11:31:41AM -0400, Marc Lavallée wrote:
The jack server was started automatically by pipewire,
even if I disabled
jackdbus in /usr/share/dbus-1/services/org.jackaudio.service (I commented
out the last line: # Exec=/usr/bin/jackdbus auto)
In my case Jack is already running. Having to restart Jack (and
everything using it) just in order to start the PW-Jack tunnel
shouldn't be necessary and is a definite no-go.
As reported before, When I start pipewire with the modified config
I get the Jack Source and Jack Sink modules, both in state 'Running'.
But no PW ports in Jack. So what is missing ?
--
FA
11:19 a.m.
On Fri, Aug 16, 2024 at 10:03:48AM +0200, Fons Adriaensen wrote:
As reported before, When I start pipewire with the
modified config
I get the Jack Source and Jack Sink modules, both in state 'Running'.
But no PW ports in Jack. So what is missing ?
Some progress... (but still not there)
I compiled the PW audio-src test program (with the autoconnect
option commented out).
Test:
- Jack is running.
- Run pipewire.
- Run audio-src.
- Run coppwr.
I have Jack Source, Jack Sink, Audio-src, Dummy and Freewheel modules.
But the modules have no ports and there are no PW ports on the Jack
side.
- Run wireplumber.
Now the ports, in both coppwr and Qjackctl, appear. I can connect
them in both places, and the 440 Hz signal from audio-src appears
in Jaaa.
- Terminate wireplumber.
The ports remain at both sides, but everything is disconnected.
But when I reconnect them, things still work.
The disturbing part here is that terminating wireplumber also
removes the PW:playback_FL -> Jaaa:in_1 connection on the Jack
side. That should definitely NOT happen.
So wireplumber is doing something that makes the ports
appear. So the next questions are: what it is doing, and
can the same be done without wireplumber.
--
FA
4:23 p.m.
Le 2024-08-16 à 05 h 19, Fons Adriaensen a écrit :
- Terminate wireplumber.
The ports remain at both sides, but everything is disconnected.
But when I reconnect them, things still work.
The disturbing part here is that terminating wireplumber also
removes the PW:playback_FL -> Jaaa:in_1 connection on the Jack
side. That should definitely NOT happen.
I tried using jnoise. In my case, the connection is removed when I
restart wireplumber.
So wireplumber is doing something that makes the
ports
appear. So the next questions are: what it is doing, and
can the same be done without wireplumber.
It looks like wireplumber is an integral part of pipewire.
(rant alert)
This system is adding to the complexity of the Linux audio stack. Even
the syntax of config files is different.
Marc
5:24 p.m.
On Fri, Aug 16, 2024 at 10:23:51AM -0400, Marc Lavallée wrote:
It looks like wireplumber is an integral part of
pipewire.
I don't think that is actually the case and stil hope that
*someone* can point out what I should do in order to make
it work as desired.
(rant alert)
This system is adding to the complexity of the Linux audio stack. Even the
syntax of config files is different.
It is certainly complex, and whatever documentation is
there is isn't very useful.
Meanwhile I've noticed another problem with the Jack Tunnel:
the port names on the Jack side are apparently taken from
the 'audio.position' property. Only a limited set of names
(the consumer surround channels) seem to be accepted, every
thing else results in 'PW:playback_UNK' and all following
ports fail to be created.
Assuming that all audio must be 'speaker signals' doesn't
make any sense - they could be anything. Maybe there is
a property to set these names, but only $DEITY knows.
And why the ports only appear when wireplumber is started
(but remain when it is terminated) is still a mystery.
--
FA
9:08 p.m.
Le 2024-08-16 à 09 h 41, Marc Lavallée a écrit :
I don't known, but It's possible to add more
audio channels if using
defined audio positions (which mean that 64 channels need to have a
set of 64 defined audio positions). I was unable to add more midi
channels. Maybe jackdbus is required...
Le 2024-08-16 à 11 h 24, Fons Adriaensen a écrit :
Meanwhile I've noticed another problem with the
Jack Tunnel:
the port names on the Jack side are apparently taken from
the 'audio.position' property. Only a limited set of names
(the consumer surround channels) seem to be accepted, every
thing else results in 'PW:playback_UNK' and all following
ports fail to be created.
I also noticed but did not mention. For a set of playback_UNK pipewire
sinks, there's only one playback_UNK jack client.
Assuming that all audio must be 'speaker
signals' doesn't
make any sense - they could be anything. Maybe there is
a property to set these names, but only $DEITY knows.
There's a spa_audio_channel enumeration :
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/include/…
AUX0 to AUX63 can be used to define an audio.position set.
And why the ports only appear when wireplumber is
started
(but remain when it is terminated) is still a mystery.
Or in a my experience, why they *disappear* when wireplumber is started.
Marc
9:29 p.m.
Am Freitag, 16. August 2024, 16:23:51 MESZ schrieb Marc Lavallée:
It looks like wireplumber is an integral part of
pipewire.
My understanding is that wireplumber is the "policy" part of PW. PW by itself
does not make connections or apply rules, that's what wireplumber is for. If
my understanding is correct [0], perhaps a way forward would be to implement a
wireplumber alternative that handles devices and connections the way you want?
That is, if you can't find a way to configure WP appropriately.
[0] I've only skimmed it to see if my base understanding is correct, but
https://pipewire.pages.freedesktop.org/wireplumber/design/
understanding_session_management.html looks like it explains the core tasks of
WirePlumber (e.g., "device enablement" and "link management" pertain
to
complaints made in this thread).
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
10:24 p.m.
On Thu, 15 Aug 2024 at 11:02, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Aug 14, 2024 at 08:28:06PM -0400, Marc Lavallée wrote:
(sorry, I'm on holidays and not really much on my computer)
Creating ports on a sink/source is part of the session manager policy.
More precisely as
part of the linking policy. Sink/source/streams can operate in
multiple modes: passthrough, DSP
or convert. The DSP mode is when port are configured with a single
channel float format and when
they are visible in JACK (we could also extend JACK to show these new
port types but many tools
tend to crash on unexpected types).
Normally Wireplumber will configure sinks/sources with their default
number of channels in DSP mode.
It will convert streams (firefox pulseaudio, ALSA clients,..) to the
DSP mode with the number of channels
of the sink they link to. This is a reasonable policy for desktop apps.
If you don't use a session manager, making a Sink/Source will thus
leave the node unconfigured. You have
however some options to do the configuration if you don't run a session manager:
1. Use the auto port config option on streams:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/m…
or on the sink/source
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/m…
2. Use pw-cli to send the PortConfig to the Node manually (i don't
have an example handy).
When I get back from holidays, I'm going to make some example config
files that implement this.
For linking ports, you can use any of the jack tools you probably
already use (jack_matchmaker) or jack_connect.
Hope this helps.
Wim
I tried and it works, but I had to upgrade Pipewire to a recent version;
I tried this:
- Copied pipewire.conf to ~/.config/pipewire
- Removed the jack-dbusdetect module from context.modules
- Added the jack-tunnel module to context.modules with 2 channels
in each direction.
Jack is running with the dbus interface disabled.
Rationale: I don't want any apps to control Jack, and dbus
is not needed to become a Jack client.
- Start pipewire
- Jack Source and Jack Sink nodes are shown in the coppwr
'graph' window, with state = Running.
But no pipewire ports are shown in the Qjackctl connections
window. The 'Info' tabs in coppwr say Input Ports = 0 and
Output Ports = 0, even if the modules or configured for 2
channels each.
No idea what to do next.
--
FA
_______________________________________________
Linux-audio-dev mailing list -- linux-audio-dev(a)lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-leave(a)lists.linuxaudio.org
11:16 p.m.
Le 2024-08-16 à 16 h 24, Wim Taymans a écrit :
For linking ports, you can use any of the jack tools
you probably
already use (jack_matchmaker) or jack_connect.
I noticed that for a jack sink configured with more than 2 channels,
with audio positions named AUX*, the MIDI port is used as the first
audio port, which of course does not work. So for a stereo player trying
to auto-connect to a jack tunnel, the left audio port is trying to
connect to the midi port of the tunnel...
But if the first audio positions are named FL and FR, the player
connects to them. I understand why it's important to name channels, but
for some use cases channel positions based on numbering would be preferable.
Marc
17 Aug
17 Aug
11:28 a.m.
On Fri, Aug 16, 2024 at 10:24:10PM +0200, Wim Taymans wrote:
(sorry, I'm on holidays and not really much on my
computer)
I don't want to spoil you holidays ! Anyway I'll be in holidays
myself in a week, so all of this will have to wait until late
September.
But meanwhile I'm more confused than ever.
You last remark:
For linking ports, you can use any of the jack tools
you probably
already use (jack_matchmaker) or jack_connect.
seems to suggest that you think that I want to use PW's Jack emulation.
That is not the case. I want to run all native Jack apps in Jack2, and
use the 'Jack Tunnel' to allow all others (e.g. a video conference app)
to connect to Jack. Or to route Jack signals to a bluetooth device.
Creating ports on a sink/source is part of the session
manager policy.
More precisely as part of the linking policy.
I really fail to understand this. If a sound card or app has N inputs
why should it ever have any other number of input ports ?
Unless a 'port' can represent more than single signal, e.g. a group
of signals that should always used together. Simplest example would be
a stereo 'port' with L and R signals. But then I'd expect such groups
be defined by the application. For example my Tetraproc Jack app has
8 inputs but logically these are 2 groups of 4: one Ambisonic A-format
input and B-format input. It makes no sense at all to group them
otherwise, nor to swap or combine signals within each group. So it's
certainly not up to a session manager to define this - it's fixed by
the app's function.
Of course in the Jack world such groups don't exist - only the port
names can be used to 'suggest' them. So at least for the Jack Tunnel
the only interpretation that makes sense is that each port represents
a single audio signal. Is there any way to set the port names, or at
least to have generic ones (numbered, starting at 0 or 1 - both make
sense depending on the situation) ?
Another mystery is the difference between context.modules and
context.objects. I used to think that the modules section somehow
defines what sorts of objects are available (by loading the code
required to create them), and the objects section actually creates
them. But that is obviously not true: the modules section contains
actual parameters for objects. And in my config I have the Jack
Tunnel in context.modules only and coppwr shows it is created and
even 'Running'.
1. Use the auto port config option on streams:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/m…
or on the sink/source
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/m…
But where should these things go in the config file ? I tried
a lot possible variations in my config file, it didn't make any
difference. That's a general problem: which properties/options
are available and where should they go ?
Finally, if that is the only solution, I could create my own
'session manager' that would just support what I need and
probably could be relatively simple. If all it takes is handling
and sending POD messages it can probably be done in Python.
Ciao, enjoy the holidays ?
--
FA
13 Aug
13 Aug
11:47 p.m.
On Tue, 13 Aug 2024, Fons Adriaensen wrote:
Below is a description of the configuration I'd
want. If anyone knows
how to do this (it shouldn't be that difficult)
It shouldn't be that difficult.... unfortunately, pipewire is pretty much
idiot proof.... or good for idiots. I don't say this as a slight against
the PW dev (team?), it is not easy to make things idiot proof while still
being mostly very usable. Just that the design goals don't align so well
with professional audio use all the time.
2. Currently the ALSA Jack plugin is used to route
audio from
web browsers etc. to Jack. PW may take over this role but
that is not a strict requirement.
You may wish to leave pipewire stopped and continue to use alsa jack
plugins
3. PW will be started manually when required, and I
don't expect
that will happen very often. It may remain running when no longer
needed but shouldn't interfere. It will be used to connect apps
to Jack as in (2), or those that even don't support ALSA, or
maybe to route audio from Jack to Bluetooth etc.
These are not pipewire design goals, I do not know how well pipewire
bridges to jackd. There is not a way that I have found to be able to
configure a PW-Jackd bridge as pulse used to have. Just sort of an on/off
switch where PW decides how many ports bridge the two in which directions
based (I think) on the number of system:* ports. I would guess auto
connect happens too.
4. All Jack ports created by PW should be permanent
and exist
as soon as PW is started, so they can be manually connected
and remain connected even when not in active use.
This is not a design goal of PW. However, it is possible to create psuedo
or passthrough PW objects that are static and use them as default desktop
"devices". As these are config file setup, they appear when PW starts.
5. PW should never ever access the sound card used by
Jack,
not even if accidentally started when Jack is not running.
It must not force Jack to use dbus in order to get access
to that card. It may manage other sound cards, but preferably
only those explicitly listed.
This is not a design goal of PW. PW does not even seem to have the option
as pulse did to configure a device as off. Instead it merely does not
spend any cpu running that device if there is no connection. I do not know
if that means the device is "opened" (and in use) or not
6. PW must never ever interfere with Jack in any way -
making
connections, trying to change the period size, etc. Its only
role is to be a well-behaved Jack client.
Supposed to be possible. The idea is to use jackd as a device for pipewire
where PW will act only as a client, accepting jackd's rate, period and
periods as they are. I have never successfully acheived this but it has
been a while since I tried.
7. I do not expect anything 'automatic' to
happen when things
are plugged in or out.
PW will not be started by plugging in a device. but if it is running I do
not know if the udev detection can be disabled or if pw can be made usable
if udev is disabled.
8. The PW configuration should be done in such a way
such that
it can't be modified by drop-in files from the system package
manager. All configuration should be manual and explicit, and
easy to verify without having to scan a myriad of files and/or
directories and trying to understand how they interact. This
is just basic security.
Config files are pretty much standard linux. The package uses /usr/share/*
for package default settings which may change but these can be overridden
with system wide settings in /etc/* which can be overridden with user
settings in ~/.config/*. So if all config options are set one way or the
other in ~/.config/, a new package config file will not change anything
unless config options are added or removed in a new version. New config
options should not happen too much now that v1.0 has happened.
I grew up with analog components where one could always see where the wire
went and plugs were not likely to jump out of one place and connect to
another, nor were pedals someone brought into the room likely to just find
a conveient place in my signal chain to insert themselves. Pulse and now
pipewire are more like the ghettoblaster.....
PW has a design goal of replacing pulse, ALSA direct connections and jackd
all at the same time. It does this well enough for many people but does
not cover everything. So far, it has been fine (if I don't look too close
at the very cluttered jack graph) for my use but from the little I know
about some of your projects I expect it will not meet all your needs.
Currently, I am not doing enough with computer audio as it matters.
Some things I would like to see in pw:
jackd-pw bridge:
as many as needed
ports=number and direction
pw side buffer size
auto connect=disable
devices:
Jack graph master device (or media clock master)
That can't be changed by the desktop GUI. That is
this is different than the default i/o device
device ignore
The device doesn't show up on the pw or jack graph
and is not opened or locked
new device ignore or active devices list
imutable device names
At least so long as the same device is plugged into the
same physical USB port (many usb devices do populate
the serial number field)
User settable device names
I could list more and maybe by now some of these are already possible.
Nicer docs would help a lot but really the docs are not that bad either.
--
Len Ovens
www.ovenwerks.net
14 Aug
14 Aug
1:42 a.m.
On Tue, Aug 13, 2024 at 5:56 PM Len Ovens <len(a)ovenwerks.net> wrote:
It shouldn't be that difficult.... unfortunately, pipewire is pretty much
idiot proof.... or good for idiots. I don't say
this as a slight against
the PW dev (team?), it is not easy to make things idiot proof while still
being mostly very usable. Just that the design goals don't align so well
with professional audio use all the time.
I dunno... I'm an idiot with a Focusrite Scarlett 2i2 3rd Gen -- which I
idiotically bought on the recommendation that it worked well with Linux --
and every time I start a WebRTC application, or sometimes VLC, it's a crap
shoot: Will it give me some sort of weird flanging noise or won't it. When
it wacks out, I end up rebooting some random number of times until it
decides to work.
9:06 a.m.
On Tue, 13 Aug 2024 19:42:20 -0400
Kevin Cole <dc.loco(a)gmail.com> wrote:
On Tue, Aug 13, 2024 at 5:56 PM Len Ovens
<len(a)ovenwerks.net> wrote:
It shouldn't be that difficult.... unfortunately, pipewire is pretty much
Not wishing to derail the original topic but are you aware that focusrite are
now supporting an independent guy who is producing linux drivers?
For the whole story see here:
https://linuxmusicians.com/viewtopic.php?t=23272
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
idiot proof.... or good for idiots. I don't
say this as a slight against
the PW dev (team?), it is not easy to make things idiot proof while still
being mostly very usable. Just that the design goals don't align so well
with professional audio use all the time.
I dunno... I'm an idiot with a Focusrite Scarlett 2i2 3rd Gen -- which I
idiotically bought on the recommendation that it worked well with Linux --
and every time I start a WebRTC application, or sometimes VLC, it's a crap
shoot: Will it give me some sort of weird flanging noise or won't it. When
it wacks out, I end up rebooting some random number of times until it
decides to work.
11:59 a.m.
On Wed, Aug 14, 2024 at 08:06:13AM +0100, Will Godfrey wrote:
Not wishing to derail the original topic but are you
aware that focusrite are
now supporting an independent guy who is producing linux drivers?
For the whole story see here:
https://linuxmusicians.com/viewtopic.php?t=23272
The most recent post there is from 2021. And reading it I don't
have the impression that Focusrite is 'supporting' this guy...
Ciao,
--
FA
1:19 p.m.
On Wed, 14 Aug 2024 11:59:05 +0200
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Aug 14, 2024 at 08:06:13AM +0100, Will Godfrey
wrote:
Sorry, wrong thread. This is where things get interesting:
https://linuxmusicians.com/viewtopic.php?p=160833#p160833
Also, the most recent post from Geoffrey in the other thread is
1st August 2024.
Incidentally, his drivers should appear in a Linux kernel near
you soon :)
--
Will J Godfrey
Not wishing to derail the original topic but are
you aware that focusrite are
now supporting an independent guy who is producing linux drivers?
For the whole story see here:
https://linuxmusicians.com/viewtopic.php?t=23272
The most recent post there is from 2021. And reading it I don't
have the impression that Focusrite is 'supporting' this guy...
Ciao,
11:39 a.m.
On Tue, Aug 13, 2024 at 02:47:53PM -0700, Len Ovens wrote:
These are not pipewire design goals,...
...
This is not a design goal of PW.
...
This is not a design goal of PW.
On <https://docs.pipewire.org/page_config.html>:
"One of the design goals of PipeWire is to be able to closely
control and configure all aspects of the processing graph."
If that is true, then nothing of what I mentioned before should
be a problem.
To 'closely control' things IMHO includes having the option to
disable anything automatic. If for example I can't tell pipewire
to not use a particular sound card that is the exact opposite
of providing control.
Config files are pretty much standard linux.
...
That's another issue which I didn't even want to mention
originally.
As long as you consider only the files and assume that either
only one of them is used or able to completely override the
others the situation is clear. It's a good system, allowing
the distro to provide 'convenient' defaults, while still
allowing the admin or user to override them.
But what about the drop-in directories ? If for example I have a
~/.config/pipewire/pipewire.conf, indicating that I want to take
matters into my own hands, does that mean that the files in the
drop-in directories in /etc and /usr/share are ignored as well ?
Or do I have to override each and every one of them ? The real
semantics of this are not clear at all.
And then there is this:
<https://docs.pipewire.org/page_man_pipewire_conf_5.html>
"Dictionary sections are merged, overriding properties if
they already existed, and array sections are appended to."
So can a 'user' config really override the 'distro' one ?
This sort of thing has indeed become 'standard linux', it's
not just a pipewire issue. Systemd is an order of magnitude
worse.
Ciao,
--
FA
5:40 p.m.
On Wed, 14 Aug 2024, Fons Adriaensen wrote:
The effect should be, if we think in terms of a sh or bash script
. /usr/share/PW/pipewire.config
# actually there would be a list of these
. /etc/PW/configfile
# again more than one file
. ~/.config/PW/config.files
On Tue, Aug 13, 2024 at 02:47:53PM -0700, Len Ovens
wrote:
Then there is a long way to go.
These are not pipewire design goals,...
...
This is not a design goal of PW.
...
This is not a design goal of PW.
On <https://docs.pipewire.org/page_config.html>:
"One of the design goals of PipeWire is to be able to closely
control and configure all aspects of the processing graph."
If that is true, then nothing of what I mentioned before should
be a problem. To 'closely control' things IMHO includes
having the option to
disable anything automatic. If for example I can't tell pipewire
to not use a particular sound card that is the exact opposite
of providing control.
I agree. I have not found a way to tell PW to ignore a device. I think the
'closely control' means PW controls things closely automatically. Many
things can be configured but this means preconfigured not on the fly
configuring. The target users are desktop and device firmware (like audio
for a car). The jack graph control is not what you or I are used to, there
are some parameters that can be changed on the fly but none of them seem
to be universal. Each node can have differing parameters. A desktop app
that asks for a SR and buffer size will be given that at the point it
connects to the graph and if the node it connects to is not currently in
use, then that node or device will also get set to the parameters the
application asked for. Otherwise pw will insert an SRC block in between.
(automatically rather than telling the application that rate/buffersize is
not available)
So your idea (and mine) of what 'closely control' means and PW's idea
would seem to be at variance. Certainly there are no GUI or CLI utilities
available that I am aware of that would make configuring PW an easier
task (I don't think it will ever be easy). The main problem is finding out
what parameters exist and then in many cases what those parameters
actually do. I have seen many queries about latency, for example, where
the user expects one latency but gets another because there are more than
one (maybe three or four?) parameters that might effect this.
I think PW wants to support profesional audio requirements but doesn't
have a clear understanding of what that might be in all it's uses. To be
fair, there are many (semi?)profesional audio uses where PW works just
fine.
Config files
are pretty much standard linux.
...
That's another issue which I didn't even want to mention
originally.
As long as you consider only the files and assume that either
only one of them is used or able to completely override the
others the situation is clear. It's a good system, allowing
the distro to provide 'convenient' defaults, while still
allowing the admin or user to override them.
But what about the drop-in directories ? If for example I have a
~/.config/pipewire/pipewire.conf, indicating that I want to take
matters into my own hands, does that mean that the files in the
drop-in directories in /etc and /usr/share are ignored as well ?
Or do I have to override each and every one of them ? The real
semantics of this are not clear at all. And then there is this:
<https://docs.pipewire.org/page_man_pipewire_conf_5.html>
"Dictionary sections are merged, overriding properties if
they already existed, and array sections are appended to."
So can a 'user' config really override the 'distro' one ?
That should mean that they are merged as above. Package params are read
in first, then system params which add to or replace, then user. There
are, however, sets of commands that are used like script snippets that do
not like to be run more than once. For example, I took
/usr/share/pipewire/jack.conf and copied it to ~/.config/pipewire/ so I
could edit it to my liking. I found there is a section called jack.rules
that caused errors unless I removed it. So it would seem that one would
have to use one's config to first remove a rule and then reset it. These
rules are application specific. I would suggest by reading the list of
settings these rules change, that they could all be moved to more
universal settings as in all cases it seems the settings changed make PW
more jack like not less. I did not find the method to use to remove these
rules (I didn't look very hard either).
To be honest, my personal preference would be to use pipewire in place of
pulse with a user defined set of pw-jack bridges and use jackd as I have
in the past. I would like to be able to tell PW to use only devices I give
it or none for that matter. Some of this may be just laziness (or lack of
time) figuring out a new system but there also seem to be things I want to
do that PW just won't allow me to do.
This sort of thing has indeed become 'standard
linux', it's
not just a pipewire issue. Systemd is an order of magnitude
worse.
I would add the unusable Gnome desktop and the set of apps that surround
it that do not allow the user to set their colour schemes, that do not
allow good contrasting title bars so one can see at a glance where focus
is, a broken menu system.... the list goes on.
One of the things that has always attracted me to Linux has been the
configurability to fit my purposes. This seems to be getting harder.
--
Len Ovens
www.ovenwerks.net
15 Aug
15 Aug
12:03 p.m.
On Wed, Aug 14, 2024 at 08:40:12AM -0700, Len Ovens wrote:
One of the things that has always attracted me to
Linux has been the
configurability to fit my purposes. This seems to be getting harder.
True, unfortunately. After nearly 20 years of using Debian for all of
my computing I gave up on mainstream Linux about 5 years ago.
My dedicated DAW systems (no pipewire, no systemd, dbus disabled) now
run on Void Linux. I use OpenBSD everywhere else.
John
17 Aug
17 Aug
9:51 p.m.
Le 2024-08-14 à 11 h 40, Len Ovens a écrit :
I agree. I have not found a way to tell PW to ignore a
device.
An easy way: when using pipewire-pulse the configuration tab of
pavucontrol can be used to disable the PW profile of an ALSA device.
There's probably a pactl invocation, a pw config, or some wireplumber
lua magic to do the same.
I think PW wants to support profesional audio
requirements but doesn't
have a clear understanding of what that might be in all it's uses. To
be fair, there are many (semi?)profesional audio uses where PW works
just fine.
What's a professional?
To be honest, my personal preference would be to use
pipewire in place
of pulse with a user defined set of pw-jack bridges and use jackd as I
have in the past. I would like to be able to tell PW to use only
devices I give it or none for that matter. Some of this may be just
laziness (or lack of time) figuring out a new system but there also
seem to be things I want to do that PW just won't allow me to do.
That's how I use PW (as a replacement for PulseAudio, but with the
convenience of using still using pavuctl).
And I can now use Jack with PW; my preference if to use a dummy device
with jackd.
But for some projects, I prefer to use only ALSA to avoid issues related
to jackd, pulseaudio or PW. Less can be more.
Marc
18 Aug
18 Aug
12:35 a.m.
On Sat, Aug 17, 2024 at 03:51:28PM -0400, Marc Lavallée wrote:
What's a professional?
(IMHO)
Someone who is paid for his/her work, the purpose and sometimes the
methods of which is/are defined by someone else rather than chosen
by him/herself.
A professional will have extensive domain-specific knowledge,
may have to work to accepted 'industry standards' and will face
monetary and/or reputational consequences when he/she fails.
In the audio context this could be a sound engineer, or a scientist
or technician using audio equipment and software as an essential part
of his/her work, or someone very familiar with this type of work and
developing the tools used for it.
Professionals tend to use tools that are reliable and predictable.
The latter means that the tool does exactly what it is told to and
nothing else. And that is the reason why I wouldn't consider PW fit
for professional use, unless it can be configured once and for all
to not have a mind of its own.
When I'm recording a live performance, or my output goes to a 50 kW
PA system or a broadcast network, I do not want the system to be
'smart' and reconfigure things just because something new is plugged
in, or because some app thinks it is so important that it needs to
produce some noise to get my attention [1]. Or anything similar.
[1] As actually happened many years ago when some stupid
Gnome CD burner app damaged two very expensive speakers by
sending a 0 dB jingle to a system set up to produce 85 dB
SPL at -18 dB working level. Since then I've banned all
'desktop' audio, and anything that autoconnects to Jack's
system:* ports.
Ciao,
--
FA
11:34 a.m.
On Sun, 18 Aug 2024 10:02:21 +0100
John Rigg <ladev9(a)jrigg.co.uk> wrote:
On Sun, Aug 18, 2024 at 12:35:46AM +0200, Fons
Adriaensen wrote:
And here!
One (the only) good thing I discovered about PulseAudio is that if you delete
the PA *server* all those annoying beeps and burps are silenced while the
programs sending them still work, so you can use Jack/Alsa without interference.
--
Will J Godfrey
...
Since then I've banned all 'desktop' audio, and anything
that autoconnects to Jack's system:* ports.
Same here.
7:55 a.m.
On 2024-08-17 12:51, Marc Lavallée wrote:
Le 2024-08-14 à 11 h 40, Len Ovens a écrit :
Well, I start up the "Pulseaudio Volume Control" and the configuration
tab yields no disable or off as it used to. I try starting it from the
command line and find pavucontrol is not installed but pavucontrol-qt
is. SO I try to install pavucontrol and it wants to install pulse (which
tends to replace pipewire)... Thanks buntu.
I will have to see if there some other way or if some profile has been
left out.
I agree. I have not found a way to tell PW to
ignore a device.
An easy way: when using pipewire-pulse the configuration tab of
pavucontrol can be used to disable the PW profile of an ALSA device. There's probably a pactl invocation, a pw config,
or some wireplumber
lua magic to do the same.
Which should be plainly documented and easy to find.
--
Len Ovens
www.OvenWerks.net
126
days inactive
131
days old
linux-audio-dev@lists.linuxaudio.org
33 comments
9 participants
participants (9)
-
Fons Adriaensen -
John Rigg -
Kevin Cole -
Len Ovens -
Marc Joliet -
Marc Lavallée -
Robin Gareus -
Will Godfrey -
Wim Taymans