Becomes more sluggish with USB headset

Just started to work with HearThis. Found when moving between books/chapters a little sluggish in that it takes time for the text to sort itself. When using a USB headset, this sluggishness increased considerably. Am I missing something?

Using HT 2.0.120 and PT8 files (whole Bible), running on Dell i5-4300u with 8GB RAM, Win10pro, Logitech H390 USB headset.

Any input welcome.

Hi John,
I can’t think why that would be. Try restarting your computer, try opening the Windows Task Manager (control-shift-ESC) and see where the cpu is busy.

The most likely causes for sluggishness would be disk IO (retrieving the data from Paratext) or rendering the text if it uses a complex script. Neither of these would seem to be related to the USB headset. So unless there’s a driver problem or some other software doing something strange when the headset is connected, I also don’t have any ideas. Hopefully following John’s suggestion will shed some light on it.

I also just started with this software and noticed the same problem. The program was very sluggish. I wondered if this had anything to do with the fact that I had both, PT 7&8 installed, because the program kept noticing that I had both. So, I uninstalled PT7 and only kept PT8, and now the sluggishness is gone.

It would be very surprising if the performance problem were directly related to having both versions of Paratext installed. Although HearThis does detect both, it only informs you just in case you happen to be trying to access a project that has not yet been migrated from PT7 to PT8. It only accesses the data from Paratext 8. If the performance improved after uninstalling PT7, it is most likely sheer coincidence, unless maybe your disk was so full that uninstalling 7 gave it enough breathing room to perform better. So far, I think all the reported performance problems for HearThis have turned out to be related to other processes running on the computer (virus scans, malware, installation of updates, etc.).

I think you’re right, that this was just coincidence. The sluggishness did come back but now it’s gone again. Will have to check what other processes might be causing this


I will like to give an update on where I am with this.

First, what I meant by being sluggish is this. Selecting the next chapter, book etc, the words that initially appear are not in proper order. It takes maybe 5 or so steps to arrange itself as it is meant to be. With only my computer, each step is a fraction of a second. With a USB head set, each step takes close to a second.

I too had both PT7 and PT8. I uninstalled PT7 and renamed the folder containing PT7 project files, on the slight chance that HearThis was using the wrong files. But I did not see improvement. I purchased another USB headset but not really much improvement. This week I will install HearThis and PT8 onto another computer and see if it is my computer.

HearThis is working, but something is not quite right. Likely something simple, something I am overlooking. HearThis is a great idea and I really hope to bring it to the translation teams this year in the DRC. Thanks for the help.

John VanderMeer

It would be relatively simple to make the “animation” of the text optional, but if this is sluggish, it certainly means that something is happening on your computer (presumably outside of HearThis) to make it slow. But if that is the case, I would expect other things to be slow as well.

The computer seems to run well, fast with other apps, including PT8. With HearThis running, with USB headset, the computer does not seem any slower. As mentioned, I will try this in a different laptop and see. I will also try using my Scarlett Focusrite audio interface which also uses USB. If none of you are experiencing this type of a problem, then I must have a setting wrong somewhere.

I started a new topic because my problem didn’t have to do with a USB headset, but I see Martin.Knauber is having a similar issue unrelated to using a USB headset. Here is what is happening to me:

I’ve used HT on my Lenovo Thinkpad last year and don’t remember there being issues. Now, when I’m getting ready to record the Gospel of Mark, I’m having issues.

My computer spec:
i5 2.20 ghz
8 gb ram
windows 10 pro 64bit.
Latest version of HT .127

I open HT but it seems the interface is very “laggy”. When I hold the spacebar to record it literally takes 9 whole seconds before the recording light moves from blue, to red, to green and actually starts recording. When I change verses or chapters the animation takes WAY too long to change over to the new set of text.

I checked my task manager and I have nothing else consuming my processor or ram. It shows HT is using 31% of my processor which seems like a lot to me. Is that normal for HT?

My computer runs all of my other programs fine. I’m not sure what is going on. Anyone have any suggestions? Is my computer too old, or slow?


Hi Casey,

I started a new topic because my problem

Alas, this is still under a topic named “Becomes more sluggish with USB headset”

Here are some diagnostic things to check into:

Does it happen when you first start up HT, or after a while?
Does the Task manger show CPU usage going anywhere near 100% during recording?
Does the TM show Windows Defender or other anti-malware spiking during this period? Does it help if you disable them?
Does other recording software work fine?
Are there any audio-enhancement things on your computer that can be disabled?
If you make a new project and use the sample data, does it still happen?
Does it matter where you are (book/chapter/verse)?

  • It happens from the beginning of me starting up HT.
  • No, when I start recording Task Manager shows that HT drops significantly to 2% or so.
  • There are no anti-malware programs running in the background.
  • I have run Audacity and it runs speedily and records fine.
  • No other audio enhancements.
  • I just tried another project and it seemed to work alright. It was a little delayed in switching between verses, but usable! I switched back to my Mark project and it started working better. That was the only thing I did was switch projects, then switch back.
  • When having the problem, it didn’t matter where I was (book/chapter/verse).

While going through these questions it seems like my problem was solved by switching between projects and then going back to my previous project I was having problems with. Seems strange, why do you think this is? Glad it seems to be working though!


My best guess is that it was some weird transient problem. It’s possible that something unusual happened that put the recording component into a state where it was stuck spinning its wheels. Sorry, not a very helpful technical explanation, but hopefully whatever was wrong won’t come back. If it does, please let us know.

John, Did you ever figure out a solution to your problem. (Or gather any useful information that might give us something more to go on?)

Thanks for the responses. So I’ve done a little playing around with my PC and HT and my external Blue Snowball mic. Here is what is going on so far. We hope to start recording Mark next week so I’m trying to find a solution before then.

I uninstalled HT and started with a fresh copy of v. 127 I made sure all my background processes were closed and my computer was running as fast as it could be. I have 8 gb of ram and an i5 2.2 processor.
I have tried using different projects of varying sizes and the results seem to be the same.

When I record with the built in mic on my Thinkpad the program seems to run fine. There is small lag while switching from line to line though. When I press and hold the spacebar it takes about 3 seconds before recording starts. When I plug in my external usb Blue Snowball mic it slows HT down a bit. menu changes take longer, the time between pressing the spacebar and recording takes about 5 seconds now.

The delay in recording is a bit annoying, but I could live with it. For some reason both the internal mic and the Snowball mic are recording at very low levels. I’ve checked in Audacity and the wave forms are really small. I’ve tried updating my audio drivers but it didn’t help. I read about a program called “Voice Meter” that can help boost the gain of the mic. I installed it and tried using that and it helped a lot. The problem is, when running that program and telling HT to use the Voice Meter’s output as the default for recording, really slows the program down. HT now takes 11 seconds after holding the spacebar before recording happens. Maybe I should abandon this 3rd party software solution and deal with the low volume recording levels? I don’t know if you have any suggestions or not but it would be helpful. Thank you!

Casey, I feel like we need to find you someone more knowledgeable about computer audio issues. There’s clearly some driver issue going on… my only idea is, could some anti-malware thing be interfering? When my own machine suddenly slows down, a look at the Task Manager often shows that Windows Defender has told something to pull over and is busy frisking it.

I wonder if you can get in touch with some technicians in International Media Services (formerly Vernacular Media Services)? Maybe @tom_bogle can get someone local at JAARS to chime in here?

I have reached out to Chet Mattheson and Jon Barker at IMS to see if they can help. I sent them an e-mail with a link to this topic. They didn’t have any immediate solutions, but they’re wondering if you might have access to another computer there that you could try to see if it has the same problems. On my computer (Intel i5-7300U CPU @ 2.60GHz, 2701 Mhz, 2 Core(s), 4 Logical Processor(s) w/ 16 GB RAM, running Windows 10 64-bit), using either the internal mic or my USB headset, the delay between pressing the record button and having it turn green is much less than 1 second. So although it is a concern that the USB mic is increasing the delay, I think that the delay from the built-in mic is already much higher than is expected, so that is indicative of a problem. Since you’re not having the problem with Audacity, it would suggest that there is some kind of conflict with HearThis itself. HearThis uses a library called NAudio for the actual gathering of data from the mic. It is not ~0 latency, but under normal circumstances, it should be entirely sufficient. As a test, you could download this simple voicerecorder demo app, created by the guy who made NAudio. If you have the same latency issues with it, then at least we know the problem is not specific to HearThis.

USB mics are known to sometimes have some latency. One possible source of the problem is that your mic may be USB 3.0, but it may be connected to a USB 2.0 or 1.0 port. Do check to see if all the ports on your laptop are the same, and if not, make sure you are connecting the mic to the fastest port.

It appears the YETI microphone settings are all controlled by the Windows Sound properties.

From Yeti Snowball manual:

(WINDOWS 7, 8.1, OR 10)

  1. Connect to your PC using the provided USB cable.
  2. From the Start menu, select the Control Panel.
  3. From the Control Panel, select the Sound icon.
  4. On the Recording tab, right-click on Blue Snowball
    and select Properties.
  5. Select the Level tab, and select appropriate
    volume level (start at midway point of
    the slider & adjust from there)

There is a switch on the mic settings of “1” “2” or “3”. Make sure it is set to “1”. If it is set to “2” that lowers recording levels by 10db.

There is a lag with any USB microphone. I have a USB YETI Blue microphone and did a quick test with a Win7 desktop running the latest version of HearThis. There was no delay when clicking the record button to when it started recording, but there’s a very slight delay from when I speak and then hear in Headphone or Speakers. I"ll try the voicerecorder demo app mentioned as well.

If there was a buffer setting in HearThis, that could fix the latency issue, but I haven’t been able to find it.

How to resolve latency issues:

In addition to working with a fast computer, the recording software you use might be able to compensate for latency through its audio/playback “buffer,” which can be set in the recording program’s “preferences.” Generally speaking, a longer buffer time (which creates more latency) gives your computer more time to process the audio, thus reducing the potential for errors. A shorter buffer time (less latency) means your computer will process the audio more quickly, but this will also increase the potential for recording errors. It is also best practice to close all other programs while recording to allow your computer to process the audio as efficiently as possible and reduce the chance of errors.

Another way to reduce potential USB microphone latency is to use a mic that has a headphone output. This will allow you to monitor the audio directly from the microphone, before any latency can be introduced (zero latency monitoring). To configure your computer to work properly with the headphone output you will need to access your Sound settings and make the USB audio device the Input/Recording device and make your computer’s default soundcard the Output/Playback device. Please consult the owner’s manuals for your USB audio device and your recording software for additional setup instructions.

Because HearThis is not really designed for a highly technical audience, we have not exposed any of the settings that would allow a user to tweak the size or number of buffers. The built-in settings (which are the NAudio defaults) do seem to work well for most users. Specifically, there are three 100-ms buffers. That said, it would be technically possible to expose these settings if we thought it would help. My impression, however, is that tweaking the buffers will primarily affect the way the audio is processed once recording actually begins. If I’m understanding things correctly, the buffer itself should only result in ~1/10 of a second of latency. A delay of more than 3 seconds to actually start the recording process seems to be something else. It looks like NAudio makes two asynchronous calls to the device when the user clicks the button to start recording. One is to “open” the device (calls waveInOpen in winmm.dll), and the other is to “start” (calls waveInStart in winmm.dll). I’m assuming that one or both of these calls is probably where the delay is happening.
We could possibly try to create a new version of HearThis that logs events and see if we can pinpoint more accurately where the delay is happening, but I’m not particularly confident that this is going to reveal anything useful.