Bug 410637 - Do not show microphone icon when an application (like PulseEffects) is using a recording PulseAudio sink monitor
Summary: Do not show microphone icon when an application (like PulseEffects) is using ...
Status: CONFIRMED
Alias: None
Product: plasma-pa
Classification: Plasma
Component: general (show other bugs)
Version: 5.16.5
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-06 06:57 UTC by Giusy Digital
Modified: 2020-01-17 09:19 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Giusy Digital 2019-08-06 06:57:14 UTC
SUMMARY
Because of a bad implementation, Plasma is showing the microphone icon in the system tray when PulseEffects is running, reporting that "PulseEffects is using the microphone". Read here for more info: https://github.com/wwmm/pulseeffects/issues/547#issuecomment-517027185

As explained in the reported issue, PulseEffects loads a virtual monitor sink where it records the input stream, but this sink should not be considered as a real microphone the user is using.

So Plasma should only consider non-virtual recording sinks to show the microphone icon in the system tray.

STEPS TO REPRODUCE
1. Install and launch PulseEffects.
2. Launch any audio/video stream from whichever application
3. PulseEffects pipeline will be initialized and a microphone icon is showed on the system tray even if the user is not really using a microphone.

EXPECTED RESULT
No microphone icon showed, unless the user will really connect and use a microphone on its system.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.16.4
KDE Frameworks Version: 5.60.0
Qt Version: 5.13.0
Comment 1 Kai Uwe Broulik 2019-08-06 07:18:50 UTC
I ran the commands in the GitHub ticket:

pactl load-module module-null-sink sink_name="test"
gst-launch-1.0 pulsesrc device="test.monitor" ! queue ! pulsesink

I get a recording stream that isn't marked as virtual:
"VirtualStream" QVariant(bool, false)
Comment 2 Giusy Digital 2019-08-06 08:02:07 UTC
(In reply to Kai Uwe Broulik from comment #1)
> I ran the commands in the GitHub ticket:
> 
> pactl load-module module-null-sink sink_name="test"
> gst-launch-1.0 pulsesrc device="test.monitor" ! queue ! pulsesink
> 
> I get a recording stream that isn't marked as virtual:
> "VirtualStream" QVariant(bool, false)

Do not know why QVariant reports it like that, but install PE and start an a/v stream, then run "pactl list sources":

Name: PulseEffects_mic.monitor
Description: Monitor of PulseEffects(mic)
Driver: module-null-sink.c
Properties:
        device.description = "Monitor of PulseEffects(mic)"
        device.class = "monitor"
        device.icon_name = "audio-input-microphone"
Comment 3 Kai Uwe Broulik 2019-08-06 11:24:08 UTC
Git commit e4cd6f30eb4ffe86147b2058a12aeabc36a181ba by Kai Uwe Broulik.
Committed on 06/08/2019 at 11:23.
Pushed by broulik into branch 'Plasma/5.16'.

[Microphone Indicator] Don't show if there are no microphones

If there are no microphones, even if there are recording streams, there's nothing for them to record other than sound playback.

Differential Revision: https://phabricator.kde.org/D22961

M  +5    -0    src/qml/microphoneindicator.cpp

https://commits.kde.org/plasma-pa/e4cd6f30eb4ffe86147b2058a12aeabc36a181ba
Comment 4 Giusy Digital 2019-08-06 12:08:38 UTC
If you tested with PulseEffects and it's resolved, close the bug. Otherwise I will test when the update is coming onto Arch Linux.

Thanks anyway.
Comment 5 Kai Uwe Broulik 2019-08-06 12:20:00 UTC
All I did was hide the indicator when you don't actually have a microphone. It will still show up if you have one. Not sure we actually want to ignore "monitors" as you can still monitor "the other side" of a conversation with them.
Comment 6 Giusy Digital 2019-08-06 12:37:44 UTC
If you mean "don't actually have microphone connected to the system", that's okay I think.
Comment 7 Nate Graham 2019-08-06 14:27:04 UTC
What if you run pulseeffects on a laptop where the microphone is built-in?
Comment 8 Kai Uwe Broulik 2019-08-06 14:27:59 UTC
Then you still get the indicator.
Comment 9 Giusy Digital 2019-08-06 14:51:55 UTC
But since it's built-in, will you get the indicator even without pulseeffects?
Comment 10 Giusy Digital 2019-08-20 11:00:09 UTC
New Plasma version landed on Arch Linux and the bug is not fixed yet. I still have the microphone indicator while I'm not using a microphone. As I said before, "pulseeffects (mic)" is an input sink monitor and it should not count as a microphone.

I think it's simple, just don't consider sinks showed as 'device class="monitor"' in "pactl list sources".
Comment 11 Giusy Digital 2019-09-08 06:44:57 UTC
New version 5.16.5 of plasma-pa on Arch Linux and the issue is still there.
Comment 12 Wellington Wallace 2019-09-08 16:17:15 UTC
Hi KDE devs! I am PulseEffects developer.

I understand that there may be a value in notifying the user that something is recording audio even if it is from a virtual sink monitor. What is odd is always telling the user that a microphone is being used. That is why they think that PulseEffects is accessing their mic when we are not doing that! The choice of name(and icon) is the real problem here.

I also wonder why KDE(or maybe QT?) is trying to detect virtual audio streams. As far as I remember you do not have this concept in Pulseaudio. Take a look at this https://freedesktop.org/software/pulseaudio/doxygen/streams.html and this https://freedesktop.org/software/pulseaudio/doxygen/def_8h.html#a6966d809483170bc6d2e6c16188850fc. There is no flag that could mark a stream as virtual. What can or can not be virtual are sources and sinks. The stream handles real and virtual devices the same way.

I imagine there is a reason why this is being made. As I never looked at KDE code I have no idea... But trying to detect virtual streams sounds a little odd when only input and output devices can be virtual.

Best regards,
            Wellington
Comment 13 Wellington Wallace 2019-09-09 22:53:44 UTC
As Pavucontrol also shows in its interface "Virtual Streams" I decided to take a look at its code https://github.com/pulseaudio/pavucontrol/blob/aa51a92b109d143d3d26c608f57d40d83a843ef4/src/mainwindow.cc#L785. There are other entries like that but in short they call virtual streams with an invalid client. For example this happens with the stream Pulseaudio creates for loopback devices. But I am not aware of another case where the client is invalid. As far as I remember any audio player using Pulseaudio has a valid client index. PulseEffects included. If that is what KDE(or QT) is using to find virtual streams our stream(created by GStreamer) and almost all of the ones you will find out there will always be marked as virtual.
Comment 14 Bobby Wibowo 2019-09-10 09:41:26 UTC
So yeah, uh, I don't know what else to add to this.
The current solution of simply checking whether any real microphone is connected won't help in my case since I'm on a laptop, with its built-in microphone "always connected".
My Logitech G633 headphone also has a microphone. It uses a "hardware switch" to disable the microphone when it's pointed upwards, but it doesn't tell the OS that it's off/muted, I believe it's simply not sending any recording stream.
I can't remember its usual behaviour in Windows, but since I'd have to install Logitech Gaming Software to make use of the headphone's extra G buttons, it'd probably tell Windows that the microphone was muted when it was disabled through the hardware switch, for appearance sake
So yeah, with/without headphones, I'd always have at least one real microphone connected anyway.
Comment 15 Philipp A. 2020-01-17 09:19:26 UTC
Hi, so I’m using panon (an audio visualizer for the plasma panel), which allows to select a source. Since it doesn’t implicitly use everything, it wouldn’t display the indicator if one chooses a sink monitor and monitors weren’t considered microphones.

> Not sure we actually want to ignore "monitors" as you can still monitor "the other side" of a conversation with them.

Well, in any case it’s not a “microphone”. I’d say optimally

1. If a monitor is being recorded, the text and icon should reflect that (maybe a stylized jack plug? https://www.iconfinder.com/icons/3545660/connector_jack_music_plug_port_sound_icon_icon)
2. There should be a way to suppress the icon in the monitor case (because of always-on visualizers).

   Idk if a whitelist of applications that aren’t considered “recording” is a good idea for this: Malware might disguise itself as one of them to avoid detection. Then again, users should be able to choose.