On Wed, 14 Aug 2024, Fons Adriaensen wrote:
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.
Then there is a long way to go.
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.
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
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
_______________________________________________
Linux-audio-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
