[LAD] Re: Pipewire

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 -- linux-audio-dev-cunTk1MwBs/[email protected]
To unsubscribe send an email to linux-audio-dev-leave-cunTk1MwBs/[email protected]