The logic in plasma/workspace/shell/osd.cpp looks correct to me:

void Osd::microphoneVolumeChanged(int percent)
{
    QString icon;
    if (percent <= 0) {
        icon = QStringLiteral("microphone-sensitivity-muted");
        showText(icon, i18nc("OSD informing that the microphone is muted, keep short", "Microphone Muted"));
        return;
    } else if (percent <= 25) {
        icon = QStringLiteral("microphone-sensitivity-low");
    } else if (percent <= 75) {
        icon = QStringLiteral("microphone-sensitivity-medium");
    } else {
        icon = QStringLiteral("microphone-sensitivity-high");
    }

    showProgress(icon, percent, 100);
}

Maybe the code that calls this is sending the old percent, rather than the new percent.

The only calling code is in plasma-pa/src/qml/volumeosd.cpp; moving to plasma-pa.

I am also experiencing this issue, and I think I've seen it even before 5.26, and on Wayland as well. For what it's worth I'm using PipeWire instead of PulseAudio as the audio server.

Operating System: Arch Linux 
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.12-arch1-1 (64-bit)
Graphics Platform: Wayland

Interestingly, this issue is not present on my Fedora laptop (Intel integrated graphics).

Perhaps Fedora is applying some patch that inadvertently fixes this issue?  Or it could be GPU related?

The hardware I am experiencing the issue on is also a laptop with integrated Intel graphics so I doubt it's that, however I can confirm that if I switch to my Fedora Kinoite 37 install instead of my main Arch Linux one the problem does not appear.

At this point both installs have Plasma 5.27.2 on them.

@Prajna can you confirm which combination of pulseaudio / pipewire your Arch Linux install is using?

Particularly, I'm interested in which alsa plugin you have installed. On my Gentoo install I have the pulseaudio alsa plugin installed, but am using pipewire as the backend. My Fedora install is using pipewire-alsa instead.

> can you confirm which combination of pulseaudio / pipewire your Arch Linux install is using?

As far as I can tell I don't have any PulseAudio server side stuff installed, only libpulse 16.1 and pulseaudio-qt 1.3 (Qt bindings for libpulse). On the PipeWire side I have pipewire-alsa, pipewire-pulse and pipewire-jack, all at version 0.3.66, plus wireplumber 0.4.13.

Just swapped my pulseaudio plugin for the pipewire one and also don't see any improvement. I'm definitely leaning towards Fedora doing something now. Would be great if we could get reports from people using other distros (I'm particularly interested in openSUSE as well) to see whether the issue persists.

I think I found the source of the problem on my Arch install, it appears to be because I had KMix installed but with autostart disabled in its settings. Deleting `~/.config/kmixrc` fixes the issue at the cost of ending up with two volume icons on the panel, and I also found that forcing KMix to never autostart by copying `/etc/xdg/autostart/kmix_autostart.desktop` and `/etc/xdg/autostart/restore_kmix_volumes.desktop` to `~/.config/autostart` and adding `Hidden=true` to both of them plus disabling KMix Daemon in the Background Services KCM also makes the issue go away.

In my case I had KMix installed due to just installing the `kde-applications-meta` package, which included KMix among a myriad of other things (I did start with just the `plasma-meta` package first but it turns out that doesn't include basic things like Dolphin or Spectacle due to those being in KDE Gear rather than being part of Plasma so I decided to just drag in the whole kitchen sink and be done with it).

So, I guess the real bug here is that KMix somehow interferes with Plasma despite not even actively running, or perhaps the fact that KMix even exists at all since Plasma has its own volume control now. It doesn't even look like KMix is meant to be used outside of Plasma since its autostart files have `OnlyShowIn=KDE` in them too.

Sorry, spoke too soon; Uninstalling KMix completely and rebooting made the problem come back, so at the moment the only solution I can find for my Arch system is in fact to have KMix autostart and the mic indicator will be fine even after killing KMix.

Interesting. I didn't have KMix installed, and installing / enabling it, having it running (or not) didn't change anything for me - indicator still had its incorrect behavior.

I will test booting from a Fedora KDE live USB on my system later and see if the issue persists.

Okay, it looks like KMix itself didn't have anything to do with it, the issue actually came back later on after a reboot or two and stayed, so I guess my fiddling with KMix and the issue fixing itself earlier today is just coincidence. I happen to have a second user account that is mostly untouched that I use for testing purposes, and so far the indicator has worked there after 6 cycles of rebooting, logging straight in to that account, starting Audacity and then using the record function (3 with KMix and 3 without).

So, the only other thing that's different audio wise between the two accounts (that I can think of) other than KMix being on by default in the testing account is that I have EasyEffects set up on my main account, so I disabled its autostart function and did 3 cycles of what I did with the other account (rebooting, logging straight in to that account, starting Audacity and then using the record function) and in all 3 the issue was gone. Then, I reenabled EasyEffects' autostart and ended up going through the testing cycle like 8x, and infuriatingly the issue disappeared somehow in 2 of those cycles, and in the others the indicator was inconsistent as it usually is. Also, so far killing EasyEffects with `pkill easyeffects` appears to fix the indicator, and starting it again does not make the issue disappear.

The most infuriating part of all this however is that my Fedora install also has EasyEffects running on startup, so idk what's going on anymore (some race condition on boot???).


TL;DR: Try killing EasyEffects if you have it running?

I don't have EasyEffects installed either. Based on the fact that it works for you using a clean user, I think the problem might be config related. Did you customize your plasma panel in any way? E.g. mine is on the top of the screen and has a global menu, window title, weather, and couple system monitors, added to it.

My panel has rather minimal customisation (all I did to it as far as I can remember is remove the peek at desktop applet and tweaking some settings in the rest), but I did try deleting `~/.config/plasmashellrc` and `~/.config/plasma-org.kde.plasma.desktop-appletsrc` and restarting plasmashell (plus rebooting afterwards as well), which reset the panel back to the default layout, and the issue occurs still (unless I kill EasyEffects, that at least has remained consistent so far).

I wonder if you happen to have multiple playback/recording devices in the Audio section of System Settings? Normally I only have one of each unless I have EasyEffects running, which then adds a sink and source there as virtual devices (although the selected playback and recording devices are still the hardware ones, EasyEffects just uses the virtual devices in the background), at this point I'm guessing that on my system at least the indicator might be looking at the wrong device when toggling mute since I don't even have any effects applied to my microphone in EasyEffects.

Hey look at that, you're right! If I disconnect / disable all input devices except one, the indicator works as expected!

Likewise, if I do have multiple input devices connected, but I select the first one in the list, the indicator also works as expected. Only when I have an input select that isn't the first one in the list is the indicator messed up. I'll change the title of this bug report to reflect this discovery.

Thus, new steps to reproduce are this:

STEPS TO REPRODUCE
1. Ensure multiple audio input devices are present
2. Select any input device as default that isn't the first one in the list
3. Open any audio input stream to prompt the microphone indicator to appear
4. Toggle the microphone indicator

OBSERVED RESULT
Popup displays incorrect information

EXPECTED RESULT
Popup displays correct information

On a side note, this could also explain why sometimes it worked fine for you after rebooting, since perhaps the order of devices got mixed up, and whenever your active input device was at the top of the list, the indicator worked fine.

Oh yeah, it does appear that in most boots EasyEffects Source appears before the hardware microphone in System Settings in my case, so then the bug appears, but sometimes the hardware microphone comes first, so then the bug does not appear. That also explains why killing EasyEffects makes the bug go away even after starting it again, since that removes and readds EasyEffects Source, therefore it ends up below the hardware microphone then.

Also, at least in my case I noticed that if I mute the EasyEffects Source specifically via System Settings in the case that it appears first the bug also disappears, and if I unmute it the mute state of EasyEffects Source follows that of the hardware microphone and the bug comes back. So far my muting the EasyEffects Source specifically is persistent across reboots, and applying effects to the microphone still works in that state, so that could be a viable workaround for fellow EasyEffects users at least.

Using Naxdy's most recent instructions, I can confirm that this bug is still present in Plasma 6.2

Bug 428757 and bug 435142 are quite relevant.

Found this bug after looking into using EasyEffects, but seems like there are quite a few annoying showstoppers for it.
Aside from the described problems of multiple sources here, EasyEffects seems to be immune to muting despite even pactl showing "Mute: yes", so I'm personally back to the usual setup disabling all input sources but the one I'm planning to use.