connected microphone false positive #133
Labels
bug
Something isn't working
Comments
bkbilly
added a commit
that referenced
this issue
Nov 1, 2024
|
Thanks for pointing this out. I've pushed an update for this and it will be available at the next release. |
|
Cheers, appreciate it |
|
I've published the new release, so you can upgrade to try out this feature. |
Thank you, I can confirm this has fixed it for me! |
|
I am seeing the false positive again today on 2024.11.0 for some reason. This is what I see while the mic is off (ie, the false positive). Let me know if there is anything else I can provide to help debug this. |
|
Update, I checked the MQTT and the topic doesn't seem to be getting updated at all (the "application" attribute isn't changing). I've run I am not sure if your code is only going through the first output or if it is misreading As this worked when I first tested I didn't check the mqtt attribute to see if the app name was being correctly reported - my HomeAssistant setup doesn't store the attributes in the history so I can't go back and find if that was working or not. |
|
Right, so I restarted and now my source-outputs is blank, and lnxlink is reporting correctly. MQTT I open Zoom, everything updates as expected: MQTT: I close zoom and
Once I connect my bluetooth headset, it breaks. Even after disconnecting, when the microphone is not being used, it leaves these "phantom" entries that cause the false positive.
|
|
@bkbilly summary here: Once I connect my bluetooth headset, it breaks. Even after disconnecting, when the microphone is not being used, it leaves these "phantom" entries in
As it is, the "phantom entry" seems to populate first on the order than the actual "true" entries. As such the mic is permanently reporting Do you think you can account for those Hope the above helps! |
|
@bkbilly sorry for the spam but I think I found a solution. from your original code for output in data:
app_name = output.get("properties", {}).get("application.name")
if app_name is not None:
return {"is_used": "ON", "application": app_name}
return {"is_used": "OFF", "application": None}I changed it so it checks for a valid, non for output in data:
app_name = output.get("properties", {}).get("application.name")
if app_name and app_name != "":
return {"is_used": "ON", "application": app_name}
return {"is_used": "OFF", "application": None}This seems to be working for me, both for no outputs and the "phantom" output returning None, and returning the valid app_name even if it's not the first in the order. I am not a dev so if you want to have a look and see if this make sense, and make the change for future versions? Thanks, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What type of installation are you running?
Desktop
Which Linux OS are you using?
aurora-dx:stable (Fedora 40)
Which version of LNXLink has the issue?
2024.10.1 (non-flatpak)
Describe the problem
After adding a new webcam with built in Microphone, lnxlink always reports "Microphone Used" as On.
The microphone isn't actually always on. When it is on, I get a "Microphone" symbol on the KDE system tray. However lnxlink fails to capture this correctly.
If I run a
pactl list short source-outputswhile the mic isn't being used I get this:If I run a
pactl list short source-outputswhile the mic is actually being used, I get the belowSo is there any potential way to capture this info so as to avoid the false positive issue?
12095 11975 12050 PipeWire s16le 2ch 48000Hz
All the false positives have an
application.name = "", so empty name inpactl list source-outputsAlternatively, is there a way to expose the application.name property from the
pactl list source-outputs?For my use in Home Assistant, I just need to be able to know I am in a meeting. The Zoom app using the microphone as per below is sufficient.
I looked at the old #54 and not sure if this is a bug or something you'd need to improve.
Thank you in advance.
Additional context
No response
Configuration
No response
Logs
No response
The text was updated successfully, but these errors were encountered: