Starting a couple weeks ago, Dragon keeps becoming unresponsive. Restarting Dragon occaisionally work and restarting the computer sometimes work, but it still happens a 5 times per day and sometimes I need to restart multiple times to fix it. Making a new profile has not worked. Any suggestions of what to try? This is really disrupting my work flow right now.

So many potential causes. In my view, the cause or causes fall into six categories: physical, electrical, environmental, behavioral, software, and expectations:

Physical: The microphone element is too far from your mouth. Over time, the microphone slips into less than ideal positions.

Electrical: The microphone or sound card is lousy or failing. Your microphone doesn't do a good job of filtering out background sounds. Your computer doesn't have enough RAM. Your USB microphone is plugged into a shared USB hub rather than directly into the computer.

Environmental: There's too much background noise, e.g., music. The window is open and street sounds are audible.

Behavioural: You leave your microphone on when you're not dictating. You have a habit of touching the microphone when dictating.

Software: Your software settings are not ideal. (Applies to Dragon, Windows, Office applications, etc.)

Expectations: You expect Dragon to perform in circumstances that it's not ideally suited for, e.g., controlling web-based apps or working with long documents.

Alan, that was a really nice structured breakdown of the sources of problems! Excellent.

-------------------------

Win10/11/x64, AMD Ryzen 7 3700X/3950X, 64/128GB RAM, Dragon 15.3, SP 7 Standard, SpeechStart, Office 365, KB 2017, Dragon Capture, Samson Meteor USB Desk Mic, Amazon YUWAKAYI headset, Klim and JUKSTG earbuds with microphones, excellent Sareville Wireless Mono Headset, 3 BenQ 2560x1440 monitors, Microsoft Sculpt Keyboard and Logitech G502 awesome gaming mouse.

Thanks for your thoughts, but it doesn't seem like these could easily explain it.

 

"Physical: The microphone element is too far from your mouth. Over time, the microphone slips into less than ideal positions."

It doesn't seem like this could be it. Dragon slows to like 1% of normal speed when this happens and readjusting my position doesn't help.

"Electrical: The microphone or sound card is lousy or failing. Your microphone doesn't do a good job of filtering out background sounds. Your computer doesn't have enough RAM. Your USB microphone is plugged into a shared USB hub rather than directly into the computer."

I use a USB microphone plugged directly into the computer. My computer has 16 GB of RAM and CPU usage is often like 10 to 30%.

"Environmental: There's too much background noise, e.g., music. The window is open and street sounds are audible."

Again, I don't think this would cause it to stop working in the way that I've described.

"Behavioural: You leave your microphone on when you're not dictating. You have a habit of touching the microphone when dictating."

I don't think this would cause it to crash like it does.

"Software: Your software settings are not ideal. (Applies to Dragon, Windows, Office applications, etc.)"

I think I'm following Knowbrainer recommendations on recommended Dragon options tweaks. Can't think of any change to this that would have resulted in Dragon crashing all the time.

"Expectations: You expect Dragon to perform in circumstances that it's not ideally suited for, e.g., controlling web-based apps or working with long documents."

I'm using it the same way I've been using it for many years. It just started doing this in the last couple weeks, without a change in how I've been using it. I don't think I am asking it to do very onerous staff.

 

See also:

KnowBrainer Speech Recognition Forums - Constant background CPU usage, even when microphone off

Skip the first couple of responses and go to Lunis's post. I quote him:

 

The last tech did something seemingly very odd. He created a Windows Administrator user and ran Dragon with no problems. He then switched back to our user profile and Dragon continued running efficiently. This certainly sounds like a stupid answer but Dragon has been running well for the last 6 months or so. It can't hurt to try out this ridiculous solution 

 

Hope that helps, Stephan

-------------------------

www.egs-vertrieb.de - www.spracherkennungscloud.de

Possibly related:  I just posted  Dragon hangs when furnace turns on - The heating season has begun (again)

 

Although you seem to have solved probably different way, I was struck by the "Starting a couple weeks ago, Dragon keeps becoming unresponsive."   Perhaps your heating season  starts earlier than mine?   Especially since I traveling a lot recently, and was in a much warmer state on the Mexican border when the 1st snowfall happened here where I live.

 

Also, I have observed over the past few years that when I start thrashing around trying to unhang Dragon

 

(a)  e.g. if I kill Dragon or restart the PC sometimes files get corrupted

 

(b)  but even if I don't kill Dragon, when there is  an ice jam  of pending  speech commands,  sometimes bad things happen even if they would not have happened originally, because I might've moved the mouse or change the window context.

 

I think that (b) actually causes more file corruption then (a).  especially if Dragon unhangs  while I am in the middle of shutting down the PC or the like.

 

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

Typically when this happens I just shut down Dragon right away before it starts eventually getting around to recognizing what I've been saying. There's basically never any hope for Dragon getting back to a usable speed once a crash like this happens for me.

Heating's been on for a couple months before this where I am. I've never noticed a connection between heating and Dragon's performance.

Ag, when you speak of an ice jam of of pending speech commands, how do you build up the backlog? Don't you have to wait for the first one to change the document, reposition the insertion point, etc before you issue the second, third, and follow-on commands? I always find myself waiting for one command to complete before heaping on the second and following commands. I do this because if the first command has an unintended effect, the second and follow-on commands don't have the proper content and just mess things up even more.

-------------------------

Win10/11/x64, AMD Ryzen 7 3700X/3950X, 64/128GB RAM, Dragon 15.3, SP 7 Standard, SpeechStart, Office 365, KB 2017, Dragon Capture, Samson Meteor USB Desk Mic, Amazon YUWAKAYI headset, Klim and JUKSTG earbuds with microphones, excellent Sareville Wireless Mono Headset, 3 BenQ 2560x1440 monitors, Microsoft Sculpt Keyboard and Logitech G502 awesome gaming mouse.

 

F**k, I started dictating an answer, and I suffered a hiccup, a sort of mini hang.    I think in this case the mini hang was caused by a piece of ordinary dictation  being misrecognized as a  command or vice versa,  and/or focus got stolen  i.e. notification from 1 of my email apps (today I  am messing around with email a bit, and I have Gmail in chrome, OneNote, Thunderbird, and eMclient all open,  them as fresh installs so I have not yet disabled all of the notifications that still focus).    anyway, upshot is I lost everything that I was dictating.  I won't redo it all, but I'll try to summarize, although even my summary will probably not make Rudiger happy.

 

1st, many of my speech commands do many steps.  frequently opening and closing multiple dialogs and menus in the same map,  e.g. in OneNote.  sometimes jumping between apps. now, I know that I should really wait in my scripts to confirm that the action has actually been completed before going on. But I don't do that as much as I should,  large part because often  simply waiting for the active window title or controlling the change is not sufficient. That's 1 of the reasons why I want to use UIAutomation, but I haven't gotten around to doing that yet.    I blush to admit that many of my scripts just have sleep times or key delays tweaked to make things work in the common case.   e.g. 1 of my favorite OneNote  speech commands  is more than 10 steps, each of which  involves sending  3 or 4 keys.

 

2nd,  sometimes things work pretty well, and I'm afraid I fall back into doing what any old-time programmer does on a UNIX system: typing ahead. The speech equivalent being dictating ahead. Certainly dictation, but also often commands. I'm not a call this a bad habit, because it's a good habit on a system that student for power users. But it's a dangerous habit on Windows with Dragon speech recognition.

 

3rd,  Focus stealing is always a threat to such long multistep commands,  Especially if not waiting carefully between each step.    This might've been what just bit me.

 

4th,  so what I do when I notice that *something* is hung?

 

Note that I say "something" is hung. Not necessarily Dragon.  fortunately (?) Dragon is not usually the culprit. Heaven knows IMAP email programs over a slow  network often have stalls. 

 

In part because  Dragon is not always the culprit I often  poke around a bit.  Perhaps I move the mouse to a different window, and utter a different speech command. Perhaps I say "save user profile" or "DRACO export Dragon stuff" (1 of my multistep commands, that I often try to do when Microsoft OneNote or an email program is waiting for the network).    Perhaps I think it's just a recognition error, and I didn't see the Results box, and  was not listening carefully enough for the beep that indicates an error. So I might repeat myself.

 

I'm trying to train myself not to do this as much,  because while the above might be reasonable things to do with Dragon is working, it can get me into trouble when Dragon is hung,  but is still accumulating input.   Or even when Dragon is not hung,  but where the application to which my speech commands are sending their events  is accepting things into the queue, but buffering them.

 

Oh and then there's my current pet peeve:   applications  which bind commands to unmodified keystrokes.    Like oh so many Google apps.     I might be dictating along quite nicely,  possibly with a bit of "speak ahead".  ordinary text dictation. But nothing dangerous. Until  some accident causes  the focus to switch from  a text input window like OneNote or this web forum, to a different window which binds unmodified keystrokes. The accident might be something like an asynchronous notification that steals focus,  or it might be  that something I said as ordinary dictation was misrecognized as a command, etc.      when ordinary dictation starts getting interpreted as commands bound unmodified keystrokes, things can go bad really quickly since I frequently am one or 2 sentences ahead of what's been inserted into the text box.

 

 

Anyway, yes, you are  100% correct:   it is safest to confirm that any particular speech command has completed  before going onto the next.   And even within a speech command,  it is safest to wait and check after  sending each keyboard or mouse event that is likely to cause a GUI change.   And for that matter it is safest to not dictate more than 1 or 2 words ahead. I know I don't do that.  I frequently "speak ahead" at least a full sentence if not more. Don't you?

 

But I suspect that part of the problem is that  I want to automate longer and longer sequences.

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

We are just spit balling but it doesn't look like you are doing anything wrong. Microphone distance from your mouth doesn't usually matter in DPI 15. RAM is fine. Environmental noise shouldn't be a problem. Leaving your microphone on, when not dictating, shouldn't be an issue either. However, 30% CPU usage is suspicious. This isn't exactly in our wheelhouse but we suspect your operating system is partially corrupted or you have a hardware problem. It might be time for a computer consultant. 

-------------------------

Change "No" to "Know" w/KnowBrainer 2022
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ex 1

As far as losing your work is concerned... Many applications support multiple undos. Have you tried pressing {Ctrl+z} as many times as necessary? Even Windows 11 Notepad (not Windows 10) include multiple undo capability

-------------------------

Change "No" to "Know" w/KnowBrainer 2022
Trial Downloads
Dragon/Sales@KnowBrainer.com 
(615) 884-4558 ex 1

Lunis, I am used to far more multiple undos than most piddling Windows applications provide. :-)

Moreover, when you're bouncing back and forth between apps, whether deliberately in your scripts or accidentally because an app popped up and captured focus, and then immediately got closed by some subsequent keystroke backed up, it is often unclear what app you need to do the undo in.

Now, I know that there have been research systems that have cross application system wide undo that can handle this. Essentially where all system activities are captured in something like a database transaction log. But as far as I know Windows doesn't have this.

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

Alright chiming in while the mind races on-call ...

IMHO, what I think you need, Ag, to make your high-end workflow a wee bit more conducive, are these two things:

1. Anchoring.  Lindsay's "Reporter", if and when released to the general public, would be quite ideal for some desktop Dragon users.  Highly unlikely that it would be an "arbitrary" anchor (let me not be presumptuous here).  But a "bespoke" anchor could still cater to your workflow nicely.  You would not lose dictation while the focus is taken away by your scripts.  The approximation from SP Auto Box with "tailored back-and-forth focus-switching" likely won't serve you much good (but could work well for others who are "more patient").

By the way, I only occasionally use anchor nowadays, despite working myself into a tizzy 3 months ago when I switched out of "embedded Dragon", and despite DMO has the "bespoke anchor" nicely built-in.  But then again I am so far from hands-free while still typing 75% of emails and typing mostly in this forum, I am a definite laggard by forum enthusiast standards.  Having said that, I also judge DMO to be utterly wanting for generic dictation, even with its "Clinical Administration" vocabulary.  Anyway, for hands-free (or nearly free) users, especially someone like yourself who likes to "multi-task" up the wazoo, anchoring can play an irreplaceable niche role.

2. VoiceMacro (or similar).  I think PG still uses it for some thing.  After 3 months of using DMO, I would in fact get back to VoiceMacro for some things if I could (yes the speedy mouse click is one of them ... part of the reason I am not as hands-free as I would like is because DMO's command recognition/execution is comparatively latent.  I don't think desktop Dragon is as snappy as VM either, FWIW).  That VoiceMacro doesn't work on hospital's Horizon VDI is a shame.

Anyhow, when you use "Draco" to alert Dragon that a command is coming, it may not be all that efficient.  It may be more efficient in some ways to segregate commands and "prose dictation" into 2 separate apps/"threads".  If I had fuller control over my work environment at the hospital, I would definitely try to have VM execute some common commands through wake word.

In your case, you could consider using "Draco", as an example, to wake up VM.  As it wakes up, it in turn pauses the Dragon mic.  Once the command is executed (not finished necessarily), VM would then go back to sleep, while unmuting Dragon.  Then you could either use Dragon to "dictate at the cursor" or dictate into an anchor, and not waste time waiting for the sequence of commands to complete - as in holding up your "ice jam".

I do a tiny bit of "multi-tasking" with multi-step JavaScript sequences within the browser (which can take up to 15 seconds for some chains as automation through the browser is just not that swift).  Even there, sometimes when I lose focus to the browser window, the chain of execution would come to a stop.  It is inconsistent.  When it happens it is quite annoying.  Of course, my grade-school level acumen in JavaScript may account for some of it.

Anyway, early boxing-week free give-away on "brain-storm" ... after the snow storm.

 

Just making sure we are talking about the same thing:

 

It's not MY scripts that take away focus.

 

It's  arbitrary other programs and notifications and OS crap that steals focus from my scripts, or from apps that my scripts are using.

 

Certainly anchoring to a single process/Windows/app would not be satisfactory, because my scripts are switching focus.    Changing my scripts  to verify that focus is where they expected  when a change of focus is  expected, coupled with notifying the anchor  code to prevent  subsequent focus stealing.

 

 

-------------------------

DPG15.6 (also DPI 15.3) + KB, Sennheiser MB Pro 1 UC ML, BTD 800 dongle, Windows 10 Pro, MS Surface Book 3, Intel Core i7-1065G7 CPU @ 1.3/1.5GHz (4 cores, 8 logical, GPU=NVIDIA Quadro RTX 3000 with Max-Q Design.

Let's consider a hypothetical scenario, which was perhaps closer to what transpired around the time your post evaporated.  Some random, inopportune (they always are) "modal dialog" popped up out of nowhere and stole your focus.  Not only that, your watchdog script (AHK or not) that's been hovering in the background like a dark, silent UAV high up the sky above ookraixx, swooped down and zapped the dastardly dialog, maybe through a hotkey or mouse-move-followed-by-click ... which shifted focus even further out.  Next thing you know, your post went up in smoke as the "collateral damage".

That's why it could be a little dangerous to use a hotkey such as "Alt-F4" to close dialogs (not saying you do ... I surely have).  When the timing is off, kaboom goes the homework.

As an imperious desktop Dragon non-user for the last 8-9 years, I daresay above happens at least once in a blue moon, to some of the desktop Dragon heavyweights around here, unless they are "disciplined" and generally refrain from doing anything "greedy".

 

And you are a "rebel", Ag!  In a positive sense of the word.

And there is nothing "avant garde" about wanting to multi-task.  Each year they are giving us more threads for the same die area, are they not?  My own longest JavaScript sequence generally runs without a hitch if I don't do anything concurrent.  But 20% of the times moving focus out of the browser causes the sequence to stall - always at one of 2 steps.  That's about the best I could manage with my limited JS skills.  Or it might be an inherent limitation.  Either way I accept imperfection.

 

Alternative is to sit there to watch the 15-second "animation".  Now that's boring.  I tried "meditative breathing".  But I'd rather click something in the meantime.  Who wouldn't want to multi-task?

 

Btw, one of my JS sequences involves a desktop modal dialog, with image stitching.  For that entire sequence, lasting no more than a couple of seconds on a decent processor, I really have to sit back and not touch the keyboard.  Or else.

 

Let's pause here and give a plug to RW, who was perhaps right in implying that Dragon is not meant for a certain, "aggressive" workflow ... I think the kind of limitations above was part of what he was alluding to.  You are also right in implying that in the end, many of the programs that run on Windows are not optimally designed to accommodate productive "multi-tasking".  For one thing, so-called "modal dialogs"/"pop-up windows" shouldn't have to steal focus in the first place, as a rule.  At the root it's probably another Redmond design flaw at the OS level, despite some recent emphasis on Windows "focus assist", etc.

 

[Edit]: Just realized there may be accessibility requirements that compel modal diaglogs, at least within browsers, to forcibly take focus in order to accommodate keyboard navigation.  But there is no reason why such operational rules could not be toggled globally as per end-user preference, just like so-called "caret browsing".

Anyway, back to "anchoring" - which is nothing but "out-of-focus" dictation, in Lindsay's own parlance.  DMPE has had that through its "hidden dictation box" for over a decade.  DMO/DPA of course, market that as a premium feature.

Is it "premium"?  I would answer affirmative if one wants to genuinely multi-task.  One can approximate it a bit, through built-in OS features such as "scroll inactive windows by hovering" - which is surprisingly handy as it won't activate, thus preserving current speech focus.  But that clearly is very limited.

Just in the last 24 hours on-call, I cleaned up my own anchoring commands so I can now use one voice command each to anchor and de-anchor (while fetch text) from WriteMonkey.  It's already proven handy.  I was just a little nonchalant in the last couple of months to not have made such little usability enhancements for myself.

The DMO anchoring command requires the user to physically click (activate) the app to be anchored, and then apply either a voice command or a hotkey to anchor it - while the app is in focus.  I'd rather not to put up with the hassle of departing my current cursor position whenever the whim to anchor strikes.  Hence the cleanup through elementary AHK steps with simple window activation followed by hotkey sending/return.

 

Now it would be even better had DMO/DPA allowed for "control-sending" of anchoring command, thus bypassing any need to "initialize" the anchored window by activating it.  IIRC, starting up the DMPE "hidden dictation box" does not require activation.  Moreover, judging by Lindsay's video, I don't think his "Reporter" utility needs initial activation in order to receive input, either, although I could be wrong.  I can appreciate that for the majority of DPI/DPG users around here, this is all "splitting hair" - in someone who is hairless. 

 

Nonetheless for hands-free users, every bit of such enhancement is useful.

Anyway, if you haven't come across Lindsay's post on his "Reporter" App and linked Youtube video within, I'd humbly suggest that it's worthwhile.  You or others will know immediately whether such feature is useful to you, just as Cortez knew right away that the glistening dirt, some call silver, was worth the trek.  Or not.

As to VoiceMacro, I would return to it pronto if hospital IT could fix the language pack conflict between Canadian English and some default US English setting on VDI desktops, which prevents the ancient MS speech recognizer from even running.