search

falkTX / Carla

Audio plugin host
https://kx.studio/carla
1.62k stars 147 forks source link

dragging pipewire "Monitor" rectangle of each device in patchbay causes regular interface rectangle to be dragged behind along with it #1476

Open ericfont opened 3 years ago

ericfont commented 3 years ago

I can drag the regular interface rectangle just fine without any side effect. But when I drag the "Monitor" rectangle for that interface, the regular interface rectangle is dragged along with it. The monitor is from pipewire.

falkTX commented 3 years ago

huh interesting. this might be because pipewire gives the same client uuid to both regular and monitor clients. carla reacts to position changes from other compatible clients (ie, 2 carla instances) so there is some oddity happening here. please report this to pipewire

netboy3 commented 3 years ago

This was discussed on the pipewire IRC and as far as I understand, giving the same client UUID to a client and its monitor is not breaking the standard, but rather a methodical decision. The recommendation pipewire offers to clients that have problems interpreting a separation between regular/monitor ports is to actually enable monitor merging in pipewire. That will create a combined node with both the regular and monitor ports. You can do it selectively to applications that have hard time dealing with it by adding the following to jack.conf:

jack.rules = [
    {
        matches = [
            {
                client.name = "Carla"
            }
        ]
        actions = {
            update-props = {
                jack.merge-monitor = true
            }
        }
    }
]
ericfont commented 3 years ago

so are you saying it is on the user to manually make such an entry in their jack rules for every jack application they use?

I think it would be nicer if there was one setting that worked globally to always have any jack app's monitor merged.

falkTX commented 3 years ago

This was discussed on the pipewire IRC and as far as I understand, giving the same client UUID to a client and its monitor is not breaking the standard

pipewire should check what existing jack implementations do regarding monitor ports and follow it by default. the separate monitor ports as it does now I would say is non-standard. neither jack1 or jack2 behave this way.

netboy3 commented 3 years ago

so are you saying it is on the user to manually make such an entry in their jack rules for every jack application they use?

I think it would be nicer if there was one setting that worked globally to always have any jack app's monitor merged.

See my post above. Creating a filter rule is a feature that allows you to apply this selectively. You absolutely can turn this on globally. Take a look at jack.conf in the # global properties for all jack clients. The attribute is already there, you just have to uncomment it.

netboy3 commented 3 years ago

This was discussed on the pipewire IRC and as far as I understand, giving the same client UUID to a client and its monitor is not breaking the standard

pipewire should check what existing jack implementations do regarding monitor ports and follow it by default. the separate monitor ports as it does now I would say is non-standard. neither jack1 or jack2 behave this way.

Have you mentioned this to Wim? The bottom line is that you maintain JACK1/2, he is the Pipewire lead dev, so both of you are extremely influential in the Linux Audio community. I'm just another ignorant user trying to help and at this point I'm not sure how to sort this out (and obviously whatever I offered is basically a workaround). If you prefer, I can quote the above on IRC when Wim is in the channel and see if he is receptive to it.

ericfont commented 3 years ago

thanks netboy for clarifying.

falkTX commented 3 years ago

The idea has always been that pipewire is meant (on top of other things) to be a "stock" jack replacement. Whenever something is unclear, pipewire should just follow existing jack behaviour. It has been the case so far, so for this it cannot be any different.

If something works under jack2 but is broken in pipewire, it will always be assumed to be pipewire issue, there is no discussion needed. Anything else would stop it from being a real replacement.

ericfont commented 3 years ago

I agree with @falkTX, and so I've reported to pipewire as he initially requested I do: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1760

I used falk's comment as the issue title, because I couldn't think of a better way to put it: "pipewire should check what existing jack implementations do regarding monitor ports and follow it by default. the separate monitor ports as it does now I would say is non-standard. neither jack1 or jack2 behave this way."