[BUG?] App's Audio input selector doesn't change the capture audio input

[Abrifq]

Version 0.4.2
on Flatpak
Using pipewire 0.3.48 (+patches)

Hello,
I noticed when i check Recognize from my speakers the volume meter continued to reflect the volume of my microphone.

When I check from pavucontrol it showed that the app was actually continuing to capture from the mic.

I changed it to the Monitor of my headphones in pavucontrol, now it recognizes normally & the volume meter reflects the speaker volumes.

Is this still a current issue or is it fixed and i'm somehow out of date?

[Dark-Thoughts]

I can at least say that it does not recognize any of my output channels, making the whole app completely broken basically.

[Abrifq]

I can at least say that it does not recognize any of my output channels, making the whole app completely broken basically.

Do you have pulseaudio or pipewire installed?
Did you forward access to those with flatpak? (if not, try uninstalling and then installing again)

[Dark-Thoughts]

pctl info says "Server Name: PulseAudio (on PipeWire 1.0.7)".
In Discover it says it has access to Pulseaudio Sound Server permissions, if you mean that.

[Abrifq]

Try running it from the terminal with flatpak run com.github.marinm.songrec and send us the log/text output please.

[Dark-Thoughts]

There's no output other than this one which appeared after a few seconds of idling:
** (songrec:2): WARNING **: 11:40:06.858: atk-bridge: get_device_events_reply: unknown signature

[marin-m]

Hello!

Could you please also specify with Linux distribution (and version thereof) you are using?

Regards

[marin-m]

I have tested in a recent Archlinux build both inside Flatpak and outside Flatpak.

Outside Flatpak the source input change feature works normally.

Inside Flatpak the devices are correctly listed but the source input change feature is effectively inoperant.

More specifically, the pa_context_move_source_output_by_name function from libpulse (wrapped through the move_app_by_name and move_source_output_by_name method calls in the pulsectl Rust crate we are using) is called normally and returns no error but it has no visible effect.

This looks like a regression somewhere in the ALSA wrapper/PulseAudio/PipeWire/Flatpak chain, hard to tell where.

[Dark-Thoughts]

Hello!

Could you please also specify with Linux distribution (and version thereof) you are using?

Regards

As stated here I'm currently on Bazzite, before that I was on Nobara. Both had the same issue.

[marin-m]

According to the systemd log (journalctl -f) there is now some kind of permission check preventing from changing the input source from within Flatpak apparently

sept. 27 10:49:43 arch-vbox pipewire-pulse[1178]: mod.protocol-pulse: client 0x560830295130 [MainConn]: ERROR command:68 (MOVE_SOURCE_OUTPUT) tag:8 error:1 (Permission non accordée)
sept. 27 10:49:43 arch-vbox pipewire-pulse[1178]: mod.protocol-pulse: client 0x560830295130 [MainConn]: ERROR command:68 (MOVE_SOURCE_OUTPUT) tag:10 error:1 (Permission non accordée)

Also there is some documentation here: https://docs.pipewire.org/page_access.html + https://docs.pipewire.org/page_module_access.html

[marin-m]

After taking advice at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4326 it seems that adding the --device=all to the Flatpak manifest of SongRec fixed the issue (at least it works normally for me now on Arch, unlike with the former --device=dri permission flag).

The fix has been released and pushed to Flathub so I'm closing the issue