Accommodate switching to/from bluetooth hands free profile with WirePlumber 0.5.13

[PeterNerlich]

EasyEffects Version

8.1.2

What package are you using?

Arch (easyeffects)

Distribution

Arch Linux

Describe the bug

With WirePlumber 0.5.13, bluetooth headsets are now consequently switched from the hands free profile to an available one with better quality:

• Enhanced Bluetooth profile autoswitch logic to be more robust and handle saved profiles correctly, including support for loopback sink nodes (!739)

When an application are accessing the microphone through EasyEffects, WirePlumber does not recognize that it should switch to the hands free profile.

Expected Behavior

When an application are accessing the microphone through EasyEffects, WirePlumber should switch to the hands free profile.

Debug Log

No response

Additional Information

I'm not sure whether this is a valid issue for this repository or even possible to accommodate with pipewires/wireplumbers architecture, but I feel like this or at least the discussion probably fits here better than on the wireplumber project

[wwmm]

When an application are accessing the microphone through EasyEffects, WirePlumber should switch to the hands free profile.

I agree. I do not remember when and where but at some point an user reported this. But I do not see what could be done about this on our side. Our code does not even talk directly to WirePlumber. From an API point of view we interact only with PipeWire.

I think that this has to be improved on WirePlumber somehow. I imagine that it fails to do the autoswitch because the links to the bluetooth device are not handled by it. PipeWire filters have to be manually linked through the appropriated PipeWire's API. Most likely WirePlumber does not know about them when they are created this way.

[PeterNerlich]

I have no idea of the underlying complexity, only what I see through helvum.

I know that WirePlumber has no direct connection to EasyEffects, I was just thinking that if WirePlumber detects that an application is trying to access the microphone, EasyEffects could do the same: Detect that an application tries to access its input stream, and then itself act like an application trying to access the actual microphone stream.
Since WirePlumber apparently seems to think that EasyEffects current way of connecting is not worth a hands free profile, I thought there was something it could emulate

[wwmm]

EasyEffects could do the same: Detect that an application tries to access its input stream, and then itself act like an application trying to access the actual microphone stream.

If I remember well WirePlumber detection is based on whether there is a recording stream linked to the bluetooth device. So in other to "act like an app" in this case we would have to launch some kind of recording stream and ask PipeWire to link it to the device. I don't like the idea.

That stream would be useless for anything else in EasyEffects. It would also stay in the background wasting cpu processing silence the whole time. It probably would add complexity to the code that decides if we should unlink our filters or not based on the activity in the links recording from the virtual device. And as it does not make any sense to launch this stream when the device is not a bluetooth device we will also need extra code to make sure we do not start that stream when it will have no benefit.

From a technical point of view is doable. But it feels totally out of place. The proper fix is Wireplumber taking into account any kind of link that is getting data from the bluetooth microphone and not only the ones that come from recording streams.