17 Jan
2022
17 Jan
'22
3:56 p.m.
Hello all,
I'd like to test pipewire as a replacement for Jack (on Arch),
and have been reading most (I think) of the available docs.
What is clear is that I will need to install the pipewire
and pipewire-jack packages.
And then ?
How do I tell pipewire to use e.g. hw:3,0 and make all of
its 64 channels appear as capture/playback ports in qjackctl ?
Note: I do not have anything PulseAudio (like pavucontrol)
installed and don't want to either. If that would be a
requirement then I'll just forget about using pipewire.
TIA,
--
FA
17 Jan
17 Jan
5:03 p.m.
Hi,
Thanks for opening this thread, I find this topic very interesting and
been discussing it with some people :-)
If it might be of help, I'm on Manjaro which is Arch derivative so
probably similar and I followed the Arch guide, and tried the
'substitution' - TL:DR: I eventually reverted back to pulseaudio+jack,
for now.
On 17/01/22 14:56, Fons Adriaensen wrote:
[...]
I'd like to test pipewire as a replacement for
Jack (on Arch),
and have been reading most (I think) of the available docs.
What is clear is that I will need to install the pipewire
and pipewire-jack packages.
My problem with that set-up is that it seemed that something like Ardour
would need to be explicitly run via pw-jack so e.g.
pw-jack ardour
But then setting the samplerate (I have projects at different
samplerates), wasn't trivial.
If I understand correctly eventually pipewire will be a drop-in and the
pw-jack shouldn't be needed.
The other thing I wasn't able to figure out was how to use it as I
previously would use qjackctl
And then ?
How do I tell pipewire to use e.g. hw:3,0 and make all of
its 64 channels appear as capture/playback ports in qjackctl ?
This was also unclear for me. I use 3 audio interfaces mainly and have
dedicated qjackctl 'profiles', and that works quite well for me, so
wasn't sure how this is handled in pipewire.
If you'd be willing to share any results in this thread it would be
really useful.
My current workflow is to launch jack when needed with the correct
device / samplerate configuration when needed, only _if_ needed open a
pulseaudio sink (e.g. browser audio needed while using jack). But I
understand that's might be a very 'personal' approach to it all :-)
One interesting (yet still anecdotal?) aspect is that potentially
pipewire manages to provide better latency?
Lorenzo
5:38 p.m.
On Mon, 17 Jan 2022 16:03:03 +0100
Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote:
Hi,
Thanks for opening this thread, I find this topic very interesting and
been discussing it with some people :-)
If it might be of help, I'm on Manjaro which is Arch derivative so
probably similar and I followed the Arch guide, and tried the
'substitution' - TL:DR: I eventually reverted back to pulseaudio+jack,
for now.
On 17/01/22 14:56, Fons Adriaensen wrote:
[...]
I'm also on the 'wait and see' list. For me, Jack is just plug and play.
I'd
want pipewire to be the same. As for latency, this seems to be more to do with
my USB soundcard than anything else.
--
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I'd like to test pipewire as a replacement
for Jack (on Arch),
and have been reading most (I think) of the available docs.
What is clear is that I will need to install the pipewire
and pipewire-jack packages.
My problem with that set-up is that it seemed that something like Ardour
would need to be explicitly run via pw-jack so e.g.
pw-jack ardour
But then setting the samplerate (I have projects at different
samplerates), wasn't trivial.
If I understand correctly eventually pipewire will be a drop-in and the
pw-jack shouldn't be needed.
The other thing I wasn't able to figure out was how to use it as I
previously would use qjackctl
And then ?
How do I tell pipewire to use e.g. hw:3,0 and make all of
its 64 channels appear as capture/playback ports in qjackctl ?
This was also unclear for me. I use 3 audio interfaces mainly and have
dedicated qjackctl 'profiles', and that works quite well for me, so
wasn't sure how this is handled in pipewire.
If you'd be willing to share any results in this thread it would be
really useful.
My current workflow is to launch jack when needed with the correct
device / samplerate configuration when needed, only _if_ needed open a
pulseaudio sink (e.g. browser audio needed while using jack). But I
understand that's might be a very 'personal' approach to it all :-)
One interesting (yet still anecdotal?) aspect is that potentially
pipewire manages to provide better latency?
Lorenzo 
6:39 p.m.
I've heard of success stories -- most notably with Fedora -- and keep
circling back to it. I'm using Pop!_OS 20.04 -- which is close 'nuf to
Ubuntu 20.04 -- together with the KX Studio repositories. Cadence et
all have been my friends...
So. without knowing at all what I'm doing, I tried pipewire a few
months ago and everything became an unusable mess. I uninstalled it
all and tried again recently. While I'm not sure how to use it all,
Catia now sees a whole bunch more than it used to, and various audio
apps that I used to fuss with a bit seem to be working automatically.
I found a couple of answers to "Replacing Pulseaudio with Pipewire in
Ubuntu 20.04"
https://askubuntu.com/a/1339897/2059
https://askubuntu.com/a/1365822/2059
to be particularly helpful in getting all the wee bits working right
-- as near as I can tell.
For what it's worth, summarized here, the latest iteration of my
experiments in installing:
sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
sudo apt full-upgrade
sudo apt install libspa-0.2-bluetooth
sudo apt install pipewire-audio-client-libraries
systemctl --user daemon-reload
systemctl --user --now disable pulseaudio.service pulseaudio.socket
systemctl --user mask pulseaudio
systemctl --user --now enable pipewire-media-session.service
systemctl --user --now enable pipewire pipewire-pulse
sudo rm /etc/pipewire/pipewire.conf
sudo apt reinstall pipewire pipewire-pulse
18 Jan
18 Jan
8:25 p.m.
On Mon, 17 Jan 2022 at 16:03, Lorenzo Sutton <lorenzofsutton(a)gmail.com> wrote:
<snip
> My problem with that set-up is that it seemed that something like Ardour
> would need to be explicitly run via pw-jack so e.g.
> pw-jack ardour
You distro probably also has a package that puts the pipewire
libjack.so in LD_LIBRARY path and then you don't have to type pw-jack
anymore.
switch back to dynamic control
pw-metadata -n settings 0 clock.force-rate 0
Same for buffersize (quantum) :
pw-metadata -n settings 0 clock.force-quantum <quantum
and back to dynamic:
pw-metadata -n settings 0 clock.force-quantum 0
Wim
But then setting the samplerate (I have projects at
different
samplerates), wasn't trivial.
switch to fixed sample rate (on the fly):
pw-metadata -n settings 0 clock.force-rate <samplerate
19 Jan
19 Jan
10:10 a.m.
Hi Wim,
Thanks for the very detailed info!
On 18/01/22 19:24, Wim Taymans wrote:
Cool. Would this be done before running a jack application, e.g. Ardour?
Lorenzo.
On Mon, 17 Jan 2022 at 16:03, Lorenzo Sutton
<lorenzofsutton(a)gmail.com> wrote:
<snip
> My problem with that set-up is that it seemed that something like Ardour
> would need to be explicitly run via pw-jack so e.g.
> pw-jack ardour
You distro probably also has a package that puts the pipewire
libjack.so in LD_LIBRARY path and then you don't have to type pw-jack
anymore.
OK, I think it's an AUR package on Arch and derivatives.
I'm wondering if an application is typically able to work with both,
alsa/pulseaudio and/or jack (Ardour, Pure Data, Yoshimi, MuseScore come
to mind), how would this work?
Some of these I hardly ever run with alsa/pulseaudio, but for example I
do sometimes use musescore with pulseaudio, or even Pure Data and
Yoshimi. With the current set-up if I am running jack, then
alsa/pulseaudio will just fail, which in this case is good because it is
'forcing' me to use jack (in the application) in case something
different was set-up.
In that scenario what would pipewire prioritize? Would there be a way to
tell piipewiere 'hey now I'd like to be in jack mode as much as
possible' :-)
SMPlayer has a really simple and neat way of setting this up where in
the Output driver for audio you can write e.g. 'jack,pulse' (that's the
setting I have), and it will try to use those in that order, essentially
failing if jack isn't available and then trying pulseaudio
But then setting the samplerate (I have projects
at different
samplerates), wasn't trivial.
switch to fixed sample rate (on the fly):
pw-metadata -n settings 0 clock.force-rate <samplerate>
switch back to dynamic control
pw-metadata -n settings 0 clock.force-rate 0
Same for buffersize (quantum) :
pw-metadata -n settings 0 clock.force-quantum <quantum>
and back to dynamic:
pw-metadata -n settings 0 clock.force-quantum 0 
17 Jan
17 Jan
6:51 p.m.
On 2022-01-17 14:56:30 (+0100), Fons Adriaensen wrote:
Hello all,
I'd like to test pipewire as a replacement for Jack (on Arch),
and have been reading most (I think) of the available docs.
What is clear is that I will need to install the pipewire
and pipewire-jack packages.
And then ?
With the pipewire currently in [testing] it would even be the only thing
you need to do, as it replaces jack2 (or jack).
A good place to look for answers in regards to pipewire would be its
official wiki [1] and documentation [2].
Please note, that before pipewire-jack >= 1:0.3.43-4 is in [extra] you
will need to use pw-jack to run applications with pipewire's jack
implementation or override your ld.so.conf (see wiki on that [3]).
It should be moved this evening though and I'll try to update the wiki
afterwards to reflect this change.
How do I tell pipewire to use e.g. hw:3,0 and make all
of
its 64 channels appear as capture/playback ports in qjackctl ?
I *think* you need to use the "Pro Audio" configuration for your
specific device to make that work.
Note: I do not have anything PulseAudio (like
pavucontrol)
installed and don't want to either. If that would be a
requirement then I'll just forget about using pipewire.
Pavucontrol would be one way of doing so. It's also possible via pw-cli
[4] (Wim Taymans gave that example on IRC - #pipewire on oftc.net is a
good resource too!).
Best,
David
[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home
[2] https://docs.pipewire.org
[3] https://wiki.archlinux.org/title/PipeWire#JACK_clients
[4]
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Migrate-PulseAudio…
--
https://sleepmap.de
18 Jan
18 Jan
2:10 a.m.
Evening all.
A timely thread, for me. I've just moved to a faster PC and, with an eye
to getting pipewire working, I've installed VirtualBox (6.1.30) and made
a VM of the same distro (Mint 20.3) as on the host. I'll clone it so it's
easy to 'redo from start' when I mess it up.
I've read differences of opinion about it.
--
John. [Mint 20.3 Cinnamon, looks and feels excellent.]
21 Jan
21 Jan
11:19 a.m.
Working wonderfully well now, for me, as far as I've tested on a
hardware limited PC (Intel NUC -> Topping TP30). Amazing to be able to
run VLC into Alsa, PulseAudio or Jack, without changing anything else.
I even tried the OpenBSD output. Firefox audio always just works now.
Great to think that the quite tricky configuration of cloop/ploop etc.,
will soon be 'a thing of the past'.
Testing on virtual machines was no good although the Intel card worked.
I ended up using the 'PipeWire & WirePlumber & blueman-git PPA for Ubuntu
(>= 18.04)' after many attempts at the meson build. May be just down to a
CMake problem. Quoting meson-log.txt below.
I've found that Mint's Timeline works well and I'll be creating a snapshot,
before updating via the ppa.
My sincere thanks to all who have contributed to PipeWire (and all
Linux developers, of course). It's so good these days...
--
John.
---------------------------------------------------------------------
Part of meson-log.txt about CMake:
CMake binary for 1 is not cached
CMake binary missing from cross or native file, or env var undefined.
Trying a default CMake fallback at cmake
Found CMake: /usr/bin/cmake (3.16.3)
Extracting basic cmake information
Try CMake generator: auto
Calling CMake (['/usr/bin/cmake']) in
/home/john/pipewire-0.3.43/builddir/meson-private/cmake_ldacBT-enc with:
- "--trace"
- "--trace-expand"
- "--no-warn-unused-cli"
- "--trace-redirect=cmake_trace.txt"
-
"-DCMAKE_TOOLCHAIN_FILE=/home/john/pipewire-0.3.43/builddir/meson-private/cmake_ldacBT-enc/CMakeMesonToolchainFile.cmake"
- "."
-- Module search paths: ['/', '/opt', '/usr',
'/usr/local']
-- CMake root: /usr/share/cmake-3.16
-- CMake architectures: ['x86_64-linux-gnu']
-- CMake lib search paths: ['lib', 'lib32', 'lib64',
'libx32', 'share', 'lib/x86_64-linux-gnu']
Preliminary CMake check failed. Aborting.
Run-time dependency ldacbt-enc found: NO (tried pkgconfig and cmake)
Pkg-config binary for 1 is cached.
Determining dependency 'ldacBT-abr' with pkg-config executable
'/usr/bin/pkg-config'
env[PKG_CONFIG_PATH]:
Called `/usr/bin/pkg-config --modversion ldacBT-abr` -> 1
CMake binary for 1 is cached.
Preliminary CMake check failed. Aborting.
Run-time dependency ldacbt-abr found: NO (tried pkgconfig and cmake)
Pkg-config binary for 1 is cached.
Determining dependency 'libfreeaptx' with pkg-config executable
'/usr/bin/pkg-config'
4:24 p.m.
On Fri, Jan 21, 2022 at 4:20 AM John Murphy <rosegardener(a)freeode.co.uk>
wrote:
I ended up using the 'PipeWire & WirePlumber & blueman-git PPA for Ubuntu
(>= 18.04)' after many attempts at the meson
build.
That's what got me going as well -- or at least part of that. In an earlier
post in this thread, I summarized my steps. But I didn't do the WirePlumber
thing. So I went searching, based on your comment and found instructions at:
https://pipewire-debian.github.io/pipewire-debian/
Haven't tried those instructions yet. I'm checking them out now. Was that
where you found the "how-to"?
8:02 p.m.
On Fri, 21 Jan 2022 09:24:19 -0500 Kevin Cole wrote:
On Fri, Jan 21, 2022 at 4:20 AM John Murphy
<rosegardener(a)freeode.co.uk>
wrote:
I ended up using the 'PipeWire & WirePlumber & blueman-git PPA for Ubuntu
Yes. The same as I tested with last time, but jack_transport didn't work
for me back then. I expect you have it working by now :)
-----------
I meant Timeshift not Timeline, in my previous post...
--
John.
(>= 18.04)' after many attempts at the
meson build.
That's what got me going as well -- or at least part of that. In an earlier
post in this thread, I summarized my steps. But I didn't do the WirePlumber
thing. So I went searching, based on your comment and found instructions at:
https://pipewire-debian.github.io/pipewire-debian/
Haven't tried those instructions yet. I'm checking them out now. Was that
where you found the "how-to"? 
18 Jan
18 Jan
6:09 p.m.
On Mon, 17 Jan 2022, Fons Adriaensen wrote:
I'd like to test pipewire as a replacement for
Jack (on Arch),
How do I tell pipewire to use e.g. hw:3,0 and make all
of
its 64 channels appear as capture/playback ports in qjackctl ?
Note: I do not have anything PulseAudio (like pavucontrol)
installed and don't want to either. If that would be a
requirement then I'll just forget about using pipewire.
It depends on the reason for not using "anything" pulseaudio. Pipewire is
a replacement for jack and pulseaudio. So the "JACK" graph will show all
devices, none of which will be named system:* and some of which will go
through some sort of SRC. I think it is possible to designate one device
as master with direct sync and specified latency but the reality is that
if you wish your one device to be separate from any internal, hdmi,
webcam, etc. that will not happen. It is possible to select a device
profile of "Off" for these devices but that would mean any desktop
application will automatically use you multi channel device "as best it
can" (ie. connect it's output to all device outs). With PW it is not
possible to run two audio servers separately, one for desktop and one for
audio production. (well you can still run JACK separately... and I guess
for now it is possible to run pulse separately too, but that will go away)
Pipewire does use all the system bits that puleaudio does, such as dbus
and of course systemd. I do not think it will run without.
Of course because it is a replacement for pulseaudio, even though it may
not use any of the pulseaudio code, it's interface to the desktop
applications uses much the same interface as pulseaudio. Hopefully in a
better way.
One other thing to be aware of, PW does not load any other backend besides
ALSA. I think it does have an auto dummy device though.
--
Len Ovens
www.ovenwerks.net
6:15 p.m.
On Tue, 18 Jan 2022 08:08:56 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
Pipewire does use all the system bits that puleaudio
does, such as dbus
and of course systemd. I do not think it will run without.
If it *requires* systemd then that is a non-starter for me :(
--
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
6:48 p.m.
On Tue, 18 Jan 2022, Will Godfrey wrote:
On Tue, 18 Jan 2022 08:08:56 -0800 (PST)
Len Ovens <len(a)ovenwerks.net> wrote:
I have not tried running it without and so have no hard knowledge on that.
But do remember the source. It comes from the RH ecosystem.
However, if you are running without systemd and presumably without pulse,
why would you not just use jack? With the right device, jack is very
stable. Pipewire is trying to emulate jack and in general not improve on
jack.
--
Len Ovens
www.ovenwerks.net
Pipewire does use all the system bits that
puleaudio does, such as dbus
and of course systemd. I do not think it will run without.
If it *requires* systemd then that is a non-starter for me :(
8:28 p.m.
On Tue, 18 Jan 2022 at 17:15, Will Godfrey <willgodfrey(a)musically.me.uk> wrote:
>and of course systemd. I do not think it will run
without.
It does run fine without systemd.
If it *requires* systemd then that is a non-starter for me :(
It doesn't require systemd.
You can compile with systemd support and then you have the capability
of having systemd socket activate the server and all components. If
you don't compile it in, you'll have to start things some other way.
Wim
8:16 p.m.
Hi Fons,
As a bare minimum you would need pipewire (the daemon) and
pipewire-jack (the libjack.so client implementation). With a custom
config file you can make this work exactly like jack (see below).
The way PipeWire normally works is that when starting the daemon,
nothing is in the graph. Devices are usually loaded into the graph
(using udev for ALSA, bluez5 for bluetooth, avahi for network devices,
...) by a session manager. We have a basic pipewire-media-session and
a more complete WirePlumber session manager. All the system
integration (dbus, systemd and the automatic stuff) happens in the
session manager. You don't need to run this.
For pulseaudio compatibility, you can also install and run a separate
server (pipewire-pulse). This basically just translates pulse protocol
to pipewire protocol and makes pipewire clients for streams. You don't
need to run this either.
You'll need the pipewire git version to run a minimal setup with only
pipewire using this config:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/m…
You can change the source and sink ALSA devices, set up the channels
and format and then use pipewire -c <config>
It should be enough to run all JACK apps to test things.
pw-top is interesting, pw-profiler works like the jack2 profiler,
pw-dump for a JSON dump of the object tree, pw-link (like jack_lsp,
jack_connect), etc...
Wim
On Mon, 17 Jan 2022 at 14:56, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Hello all,
I'd like to test pipewire as a replacement for Jack (on Arch),
and have been reading most (I think) of the available docs.
What is clear is that I will need to install the pipewire
and pipewire-jack packages.
And then ?
How do I tell pipewire to use e.g. hw:3,0 and make all of
its 64 channels appear as capture/playback ports in qjackctl ?
Note: I do not have anything PulseAudio (like pavucontrol)
installed and don't want to either. If that would be a
requirement then I'll just forget about using pipewire.
TIA,
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
8:30 p.m.
On Tue, 18 Jan 2022 19:16:39 +0100
Wim Taymans <wim.taymans(a)gmail.com> wrote:
Hi Fons,
As a bare minimum you would need pipewire (the daemon) and
pipewire-jack (the libjack.so client implementation). With a custom
config file you can make this work exactly like jack (see below).
Thanks for this info :)
--
Will J Godfrey
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
19 Jan
19 Jan
3:04 p.m.
On Tue, Jan 18, 2022 at 07:16:39PM +0100, Wim Taymans wrote:
As a bare minimum you would need pipewire (the daemon)
and
pipewire-jack (the libjack.so client implementation). With a custom
config file you can make this work exactly like jack (see below).
Thanks, will try this, but mnay questions remain (see below).
All the system integration (dbus, systemd and the
automatic stuff)
happens in the session manager. You don't need to run this.
Aha, that is good news.
You'll need the pipewire git version
Will things work with the current Arch packages and do I
need git just becuase it has the minimal.conf file ?
If yes I'd prefer to use the Arch packages for now.
Questions:
* A lot of lines in the minimal.conf are commented. Can one
assume that these correspond to the defaults ? If not, what
are the defaults for all these parameters ?
What concerns me here is things like
#channelmix.normalize = true
I certainly do not want any normalisation, so do I need
to set this to false explicitly ?
* The sample rate (48000) is in many places, most of them
commented out. What is the relation between all of these ?
Why, for example, is 'default.clock.rate' commented ?
* 'quantum', 'period-size' and 'period-num' are commented
out everywhere (except in 'vm.override'). So where is
the period size defined ?
* If things like sample rate, period size, etc. are set
to some fixed values in the config, can they still be
modified by e.g. pw-metadata ? I hope not...
Ciao,
--
FA
4:18 p.m.
On Wed, 19 Jan 2022 at 14:04, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Tue, Jan 18, 2022 at 07:16:39PM +0100, Wim Taymans wrote:
Sorry, git for now. I just started to implement the last bits to make a
session manager optional.
As a bare minimum you would need pipewire (the
daemon) and
pipewire-jack (the libjack.so client implementation). With a custom
config file you can make this work exactly like jack (see below).
Thanks, will try this, but mnay questions remain (see below).
All the system integration (dbus, systemd and the
automatic stuff)
happens in the session manager. You don't need to run this.
Aha, that is good news.
You'll need the pipewire git version
Will things work with the current Arch packages and do I
need git just becuase it has the minimal.conf file ?
If yes I'd prefer to use the Arch packages for now.
Questions:
* A lot of lines in the minimal.conf are commented. Can one
assume that these correspond to the defaults ? If not, what
are the defaults for all these parameters ?
They are defaults, yes.
What concerns me here is things like
#channelmix.normalize = true
All alsa devices are wrapped in an adapter. This contains:
-> channelmix -> resample -> convert -> alsa-device
channelmix and resample are disabled when the graph sample rate
and device channels all match the adapter ports, you would configure
the same number of channels on the output as the alsa-device channels
and set the graph rate to something the hw supports.
The channelmix is mostly to support making a 5.1 sink that can downmix
to dolby or some other tricks.
The resampler is used when slaving devices or when the graph rate
doesn't match the device rate (some webcams only do 16KHz). The
minimal config disables it as well.
I certainly do not want any normalisation, so do I need
to set this to false explicitly ?
If you set the channels in node.param.PortConfig and audio.channels
to the same value, there will be no channelmixing and so no
normalization.
* The sample rate (48000) is in many places, most of them
commented out. What is the relation between all of these ?
Why, for example, is 'default.clock.rate' commented ?
default.clock.rate = 48000 is the default, If you change the graph
clock rate, the devices will follow the rate so you can just leave
them blank (the rate in node.param.PortConfig is ignored.. need
to fix that..)
* 'quantum', 'period-size' and 'period-num' are commented
out everywhere (except in 'vm.override'). So where is
the period size defined ?
The commented out values are the defaults
* If things like sample rate, period size, etc. are
set
to some fixed values in the config, can they still be
modified by e.g. pw-metadata ? I hope not...
Yes, pw-metadata (but not accessible from jack apps) overrides the
config settings and limits. I'll add a switch to disable this.
Wim
Ciao,
--
FA
20 Jan
20 Jan
1:16 p.m.
Hello, Wim,
Sorry, git for now. I just started to implement the
last bits to make a
session manager optional.
OK, I'll wait until this is available via Arch (don't want to mix up
two potential problems, build/install and configure...)
All alsa devices are wrapped in an adapter. This
contains:
-> channelmix -> resample -> convert -> alsa-device
channelmix and resample are disabled when the graph sample rate
and device channels all match the adapter ports, you would configure
the same number of channels on the output as the alsa-device channels
and set the graph rate to something the hw supports.
In the example config, node.param.Portconfig.format.channels is
hardcoded. Is there a way to obtain the number of channels the
device supports (to make sure the values match) ? ALSA does
provide this info once the devide is opened...
What will happen if the configured number of channels does not
match ? What sort of channelmix will I get ?
The channelmix is mostly to support making a 5.1 sink
that can downmix
to dolby or some other tricks.
This can be a very devious thing. I remember an occcasion some
years ago (when I was in Parma) when some students were doing
measurements in a rented anechoic room during an entire week.
Later, when the measurements were processed, they discovered
that all of them were useless because their (Windows) system
had been trying to be clever and had applied gain changes and
channel mixing without them being aware. Now work out the cost
of renting an anechoic room for 60 hours. Plus, if they hadn't
been students and 'free labour', the consultancy fees for the
same period.
For any serious work, there are things that need to be
disabled without any chance of them ever be re-enabled by
accident. The required result when something does not match
is to fail and report, not to try and be clever and 'fix'
things behind the user's back.
The idea of having the daemon do the 'plumbing' and the
session manager to define 'policies' is a very good one.
But to take that to its logical consequence, the defaults
for any optional processing (channel gains and mixing,
resampling,...) should be off and disabled. If any other
defaults make sense for the 'average user', they should
be defaults defined by the session manager, not by the
plumbing daemon.
There is one feature that would be very desirable and
for which I would even be prepared to write an ad-hoc
session manager if that is the only place it can be
done: if a sound card becomes unavailable while in use,
substitute a dummy device with the same sample rate,
period, and number of channels, so the entire processing
graph remains intact and running. Then, when the device
becomes available again, allow the user to reconnect
to it (this must NOT be automatic). This is to minimise
'down time' when someone accidentally pulls a cable
during a concert or recording (a classical orchestra
is orders of magnitude more expensive than an anechoic
room).
Ciao,
--
FA
9:11 p.m.
On Thu, 20 Jan 2022 at 12:16, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
I've added an option to disable the channelmixer and volume updates to it now.
I've also added an option to automatically configure the device with
the max amount of channels probed from the device.
I agree, I'm adding options to disable the extra automatic
things by default.
Hello, Wim,
I'll probably make a release next week.
Sorry, git for now. I just started to implement
the last bits to make a
session manager optional.
OK, I'll wait until this is available via Arch (don't want to mix up
two potential problems, build/install and configure...)
All alsa devices are wrapped in an adapter. This
contains:
-> channelmix -> resample -> convert -> alsa-device
channelmix and resample are disabled when the graph sample rate
and device channels all match the adapter ports, you would configure
the same number of channels on the output as the alsa-device channels
and set the graph rate to something the hw supports.
In the example config, node.param.Portconfig.format.channels is
hardcoded. Is there a way to obtain the number of channels the
device supports (to make sure the values match) ? ALSA does
provide this info once the devide is opened...
What will happen if the configured number of channels
does not
match ? What sort of channelmix will I get ?
It depends on the channel layout, first channels that match will be
copied, then there are some simple heuristics to make channels out of
the other ones (front center from stereo, copy front to rear channels)
or mixing channels into other ones (rear channels into stereo). This
is nothing fancy but good enough for default consumer use.
The channelmix
is mostly to support making a 5.1 sink that can downmix
to dolby or some other tricks.
This can be a very devious thing. I remember an occcasion some
years ago (when I was in Parma) when some students were doing
measurements in a rented anechoic room during an entire week.
Later, when the measurements were processed, they discovered
that all of them were useless because their (Windows) system
had been trying to be clever and had applied gain changes and
channel mixing without them being aware. Now work out the cost
of renting an anechoic room for 60 hours. Plus, if they hadn't
been students and 'free labour', the consultancy fees for the
same period.
For any serious work, there are things that need to be
disabled without any chance of them ever be re-enabled by
accident. The required result when something does not match
is to fail and report, not to try and be clever and 'fix'
things behind the user's back.
The idea of having the daemon do the 'plumbing' and the
session manager to define 'policies' is a very good one.
But to take that to its logical consequence, the defaults
for any optional processing (channel gains and mixing,
resampling,...) should be off and disabled. If any other
defaults make sense for the 'average user', they should
be defaults defined by the session manager, not by the
plumbing daemon.
There is one feature that would be very desirable and
for which I would even be prepared to write an ad-hoc
session manager if that is the only place it can be
done: if a sound card becomes unavailable while in use,
substitute a dummy device with the same sample rate,
period, and number of channels, so the entire processing
graph remains intact and running. Then, when the device
becomes available again, allow the user to reconnect
to it (this must NOT be automatic). This is to minimise
'down time' when someone accidentally pulls a cable
during a concert or recording (a classical orchestra
is orders of magnitude more expensive than an anechoic
room).
Very doable with a little lua script in wireplumber..
Ciao,
--
FA
1033
days inactive
1037
days old
linux-audio-dev@lists.linuxaudio.org
20 comments
8 participants
participants (8)
-
David Runge -
Fons Adriaensen -
John Murphy -
Kevin Cole -
Len Ovens -
Lorenzo Sutton -
Will Godfrey -
Wim Taymans