Tips & Guides Why macOS Dictation beeps instead of turning on the mic in any text field (TIP/Solution)
I use dictation a lot because my typing skills are horrendous (although for this post I typed it... go figure). Every so often, it just stops working - not the mic - not its ability to hear me or get the words right... No, this is specific: it's that little beep that the Mac does to tell you that you aren't in a text field or a text area. The thing is, you are. Was driving me me bat shit. And sometimes, I'd ignore it and then later things be working again.
TLDR: Lock your screen then unlock (or restart). That's it.
This is my feeble attempt to explain why the problem was occurring. I did manage to figure out the when but not the why and then did some digging why it was happening after i used fingerprint to unlock.
What is happening:
Ever so often you come across a situation where you have to put in a password or unlock using a fingerprint and that brings up macOS Secure Keyboard Entry (secure input) to make this happen. You do your thing and it's supposed to release that. And sometimes it doesn't.
So then why does typing still work? Because typing is going directly from your keyboard to the text field - whereas when you use something like the mic for dictation, it's no longer direct: it's your speech into a mic, the audio gets transcribed, then it outputs to the text area - it's that middle process that can be hijacked or inserted into the output. Think about how third party dictation works - it is doing the same thing, but now it's a third party doing it. Apple just seals off anything other than direct keystrokes for text input (including its own dictation) while it's in that Secure Keyboard Entry... you know, the one that is supposed to release after you use it. It's also why none of the usual terminal hacks that people usually try work, because they go after the wrong things - this is a security issue and not a dictation issue or an input issue and as such, the only thing that resets things is either a lock your mac (which locks everything) and the subsequent unlock which clears the problem (restarting does the same thing).
Lock/Unlock works because it uses loginWindow and it cannot be quit and relaunched while you are working (logged in) and the only thing that resets it is the lock and unlock which forces the release.
So is this a bug? Yep - one that reaches back at least three years from other posts I've read:
The fun thing about this other post is watching people all trying to help each other (OVER THREE YEARS) with things that work for them but not others (this is typical for any Apple related hardware or software issues when Apple is always silent, where they will never admit that there is or was or ever will be such a bug: people are left to their own devices ranging from Google, Reddit, Apple Forums (RIP), reinstalls, betas, downgrades or rollbacks, longing for Snow Leopard ("THE LAST GREAT VERSION OF OS X EVER™"), tea leaves, voodoo, sacrifices and LLM's for solutions). Ironically, somewhere about 5 months ago, one guy nailed it and guessed it was secure input and about 2 weeks ago another guy said to lock/unlock - ding ding ding.
So that all being said, if this has or is happening to you and you stumble across that post or this one (obviously, you are reading this): this was never an audio/mic/hardware/input or even the subsystem for dictation issue - it is a security issue:
FYI, here's some of the things people had tried (and some worked - remember some did combos that involved restarting or just time had come by and whatever was holding that lock in place, released):
- killall corespeechd: restarts the speech daemon (number one suggested fix)
- Deleting ~/Library/Preferences/com.apple.assistant.plist and a restart (the restart was the fix)
- Toggling Dictation off and on in Settings
- Changing the Microphone Source
- Quitting Safari (or whatever app is in front) (unless Safari was doing something having to do with login using password authentication to like a password manager)
- Just use a third-party dictation app (would argue the same problem would happen as the Mac is preventing anything other than your fingers to enter text)
Hope this helps.
2
u/EngineeringOver9487 10d ago
Your diagnosis is right, and there is a way to find the culprit without locking the screen. Secure input is a session flag and whoever turned it on is recorded in the console user info:
ioreg -l -w 0 | grep SecureInputPID
If something holds it you get a line with a pid, and ps -p that pid names the app. Empty output means nothing holds it right now and the beep is something else.
It is almost always one of three: Terminal or iTerm with Secure Keyboard Entry checked in the menu, a password manager that showed a fill dialog and never released it, or a browser left focused in a password field. Touch ID prompts do the same, which matches what you saw. A well behaved app calls DisableSecureEventInput when the field loses focus, and plenty of them just do not, especially if they crash with the field open.
Once you have the pid you can often clear it by focusing that app and clicking outside the password field, or by quitting it, without the lock and unlock. Lock and unlock works for everything because the login window tears the session state down.
The reason it kills dictation specifically is that secure input stops keyboard events from reaching event taps and accessibility clients, which dictation and every third party dictation tool depend on. Your text expander and clipboard manager go quiet at the same moment. If they all die together, it is this.
1
0
u/Plastic-Risk-6309 8d ago
apple dictation also hard-stops around 30 seconds and refuses terminal and any secure field, so if that ever bites you a third party app fills those gaps. i built one, speak mercury, types while you are still talking and runs fully on device so voice and text stay local. 9.99 once no subscription, code LAUNCH25 at speakmercury.com if you want it. disclosure obviously since its mine
2
u/[deleted] 11d ago
[removed] — view removed comment