Bug 410230 - Make it easy to listen to a microphone / an input sink
Summary: Make it easy to listen to a microphone / an input sink
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Audio Volume widget (other bugs)
Version First Reported In: 6.2.4
Platform: Other Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: David Rosca
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2019-07-26 12:20 UTC by Raphaël Jakse
Modified: 2025-02-23 17:38 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raphaël Jakse 2019-07-26 12:20:38 UTC
I wanted to listen to my phone's output through Bluetooth. It took me a long time to understand how to do it: launch pavucontrol, go to the "Recording" tab, "show all stream" and unmute the relevant loopback sink.
I just discovered that I can do this using KMix too. KMix is not installed by default, neither is pavucontrol, on a standard KDE/Plasma environment.

Listening to one's microphone seems pretty common and is done in the same way. In the current situation, a regular user would probably be unable to do this on Plasma. I think it should be an easy thing to do. Maybe using a checkbox, or (better?) by showing the loopback devices in the "Applications" tab, so they can be unmuted and the sound volume can be set. The fact that two sliders at two different places need to be adjusted for the microphone might be confusing however.
Comment 1 Raphaël Jakse 2019-07-26 14:18:32 UTC
It just occurred to me that putting microphones in the Applications tab might be a bit confusing since they are not really applications.

Solutions I see are:
 - renaming the Applications tab to "Audio sources", which seems clear and simple
 - adding a third tab, but I don't like this solution very much
Comment 2 TraceyC 2025-01-30 20:33:38 UTC
Being able to listen to an input, for example to test that a mic is working and how it sounds, seems like a common thing. Making this more discoverable seems reasonable
Comment 3 Niklāvs Koļesņikovs 2025-02-23 17:38:09 UTC
Not saying it's a bad idea but implementers should beware that playing back microphone input on speakers where it can (and likely will) get picked up by the microphone will form an audio loop and result in rather terrifying amplification and distortion. Possibly bad enough to break HW though unlikely.

Perhaps a reasonable middle ground would be to have a push to play back functionality such that if someone releases the mouse button or spacebar in a panic, the loop is immediately disconnected. Please note that stopping playback without link disconnection is probably __not__ sufficient safety net, since in rare corner cases there could be a more severe type of feedback loop that causes a self sustaining glitch that will persist until the link at fault is disconnected.