This is more accurate given the technical constraints, yeah.

but due to a lack in qt libraries

Can you elaborate on this? What is Qt lacking?

In D29312#660670, @nicolasfella wrote:

but due to a lack in qt libraries

Can you elaborate on this? What is Qt lacking?

I'm not an expert, so I don't really know. Reading the bug report, there's no way to discern input devices from monitor sinks. So if you want to report applications that are using a microphone, you end up showing applications like PuseEffects that create a monitor sink. Those applications can use a microphone but in most cases don't, because PulseEffects is mostly used to apply effects to output streams (but need to record those streams effectively).

In D29312#660702, @kurmikon wrote:

In D29312#660670, @nicolasfella wrote:

but due to a lack in qt libraries

Can you elaborate on this? What is Qt lacking?

I'm not an expert, so I don't really know. Reading the bug report, there's no way to discern input devices from monitor sinks. So if you want to report applications that are using a microphone, you end up showing applications like PuseEffects that create a monitor sink. Those applications can use a microphone but in most cases don't, because PulseEffects is mostly used to apply effects to output streams (but need to record those streams effectively).

Qt is not really involved in this. What matters is what libpulse offers, and it seems to me that we can check whether a sink is a monitor (https://freedesktop.org/software/pulseaudio/doxygen/structpa__source__info.html#a5e304b796ce71c7fa54e5a88f3333630). One would need to add a method isMonitor to Sink that reads this information and then we can not show the indicator when it's a monitor

In D29312#660704, @nicolasfella wrote:

In D29312#660702, @kurmikon wrote:

In D29312#660670, @nicolasfella wrote:

but due to a lack in qt libraries

Can you elaborate on this? What is Qt lacking?

I'm not an expert, so I don't really know. Reading the bug report, there's no way to discern input devices from monitor sinks. So if you want to report applications that are using a microphone, you end up showing applications like PuseEffects that create a monitor sink. Those applications can use a microphone but in most cases don't, because PulseEffects is mostly used to apply effects to output streams (but need to record those streams effectively).

Qt is not really involved in this. What matters is what libpulse offers, and it seems to me that we can check whether a sink is a monitor (https://freedesktop.org/software/pulseaudio/doxygen/structpa__source__info.html#a5e304b796ce71c7fa54e5a88f3333630). One would need to add a method isMonitor to Sink that reads this information and then we can not show the indicator when it's a monitor

I'm afraid applications that really use a microphone, create a monitor sink.

@nicolasfella if an application is recording directly from an input device (a simple microphone), your hint would be the solution: we should check and exclude sink source monitors.

This way PulseEffects would be correctly excluded. But I was thinking a special case which would lead to another issue. If in the future there will be (or maybe it already exists) an application that records from multiple input devices (something to mix from more than one microphone), this app should create a monitor sink to redirect every source, then it has to record from the monitor.

In this case, if we exclude applications recoding from a sink monitor, we will exclude this app that really is using microphones, which is not the primary intended purpose.

So, the best approach is to cover all cases and report "an app is monitoring something" when it is recoding from whichever source.

i think i would prefer a somewhat inaccurate message, rather than an obscuretecnicism which is technically accurate (

In D29312#662773, @mart wrote:

i think i would prefer a somewhat inaccurate message, rather than an obscuretecnicism which is technically accurate (

I don't agree, but what do you suggest considering that now Plasma is showing a wrong message?

Pulseaudio is an abstraction layer over alsa.

You, as a developer, can record sources in many ways, but since it's an abstraction layer, you can't be really sure whether the source is a microphone or not. There's a discussion on github where a user was asking on differences between speakers attached to the system and network output: PulseEffects funder said there's no difference, since Pulseaudio exposes them the same way.

Maybe there should be something to discover it in some complicated ways, but that's also too difficult to implement in a simple desktop environment applet. No offense, but who designed this indicator had in mind one only use case. Unfortunately there are also other cases and Plasma gives a wrong information in those events.

Besides, it's also not coherent. I have two laptops. On one I don't have the microphone and no message is shown.
On the other the microphone is integrated, always connected, and the message is shown: "PulseEffects is using the microphone". That's not true, I'm using PulseEffects to apply volume normalization on output sources.

What can we do? Maybe we can exclude PulseEffects with a string comparison or a reg exp from the app list? Nope, because it can record from the mic in other use case, so that would be in conflict with the applet primary purpose.

So, please, don't mock the users and let's show the truth. If you don't like "monitoring", we can say "recording", "using", "handling". But not microphone. An audio stream.