Comment 1 by jteh on 2012-03-03 03:57
Please be more specific. Do you mean the end of the utterance is snipped off/truncated? Is this only in Windows 8? Also, what build of Windows 8 are you using?

Comment 2 by challsworth2 on 2012-03-03 11:33
Basically it truncates the last word on a line. So for example instead of saying recycle bin 1 of 2 it says recycle bin 1 of then the 2 gets truncated. This is on Windows 8 Consumer Preview.

Comment 3 by parham on 2012-03-03 12:08
I also have this issue. This may be a sound card driver issue that only happens with the NVDA ESpeak driver. I have a Creative soundcard and this has happened to me with both the X-Fi Go! and X-Fi soundcards in Windows 7. I haven't tried it with Windows 8.

What I do to get around this is to play an audio file with my media player and lower the volume to 0 so I don't hear the audio file. Then nothing is cut off.

I didn't personally report this because I suspect it might be an audio card issue; this doesn't happen with Realtek High-definition audio.

Comment 4 by jteh on 2012-03-04 21:45
It does sound like an audio driver issue. We do wait for the last chunk of audio to play before we close the audio device, so these drivers must be telling us they've finished playing a chunk when they in fact haven't.

As a matter of interest, if you make NVDA play a beep (e.g. turn on playing of mouse audio coordinates and then move the mouse), does the issue go away? There is a bug in NVDA where the audio device is kept open after a tone is played, but this bug is useful for the purposes of this test. :)

Comment 5 by challsworth2 on 2012-03-04 22:15
Ok, I will do this and report back. Thanks for the update.

Comment 6 by parham (in reply to comment 4) on 2012-03-05 05:47
Replying to jteh:

As a matter of interest, if you make NVDA play a beep (e.g. turn on playing of mouse audio coordinates and then move the mouse), does the issue go away? There is a bug in NVDA where the audio device is kept open after a tone is played, but this bug is useful for the purposes of this test. :)

Well, for me at least, when I turn on progress bar beeps, they also get cut off. Not sure if the same bug exists in that case, or only when using the mouse.

Comment 7 by jteh (in reply to comment 6) on 2012-03-05 06:55
Replying to parham:

Well, for me at least, when I turn on progress bar beeps, they also get cut off.

So it doesn't fix the speech truncation? That's concerning, since the audio device is kept open in that case, which I thought was why playing something from another application fixed it. This means that keeping the audio device open for longer is not going to fix this issue.

Can someone experiencing this please install espeak SAPI 5 and test with that? I'm curious as to whether it happens there too.

Comment 8 by parham (in reply to comment 7) on 2012-03-05 08:05
Replying to jteh:

Can someone experiencing this please install espeak SAPI 5 and test with that? I'm curious as to whether it happens there too.

As the original reporter has reported, this doesn't happen with SAPI5 synths, even ESpeak (although I'm not using the Max variant in the SAPI5 version if that helps).

There are also cases where the start of utterances are truncated; e.g. when using certain headsets where nothing else has the audio device open.

Things to investigate:

• Is keeping the audio device open the entire time really bad?
  • Does it negatively impact power consumption?
  • Does it prevent standby? NVDA prevents automatic system standby #400 suggests it does, but that should be re-tested. Also, that was probably XP. Does this affect later Windows?
  • I have a headset which seems to refuse to play any audio at all if you plug it in while something is holding audio open. Is this actually valid?
• Are there any recommendations about such things? What do other applications which must play non-continuous chunks of audio do?
• We could close the audio device only after a certain time of inactivity.
  • Is this enough to prevent truncation in all cases or do we also need to inject trailing silence? Keeping the device open seems to be enough on devices I have here, but I believe this isn't true for Windows 10 with Realtek audio. @tspivey might have more info.
• If we do close the device after inactivity, this still means the start of utterances might be truncated after the timeout.
  • Is this acceptable?
  • Is there any way to work around this other than prepending silence?
  • I guess we could just prepend silence only when we have to open the device.
• When the device is open, do the start of utterances ever get truncated?
  • If so, we'll need to prepend silence in all cases... but that would cause latency.

CC @Camlorn, @michaelDCurran, @feerrenrut. In looking at this, we should also consider tones (#400).

The easiest fix for this is probably going to be to just append 100MS of zeros to the end of the audio. The following Python list comprehension produces the right amount of data:

[0.0 for i in xrange(channels*sr*duration)]

Where duration is in seconds. These arrays can be preallocated and cached pretty trivially, so performance isn't really an issue.

I think this is doable, but it's been a while since I looked at it. This can probably just be done by the method whose name I believe is idle, as other cases will cut it off anyway.

If audio is being cut off at the beginning, this is just something else to add to the "do we need an audio settings dialog?" discussion. There is no other way to fix this that I am aware of besides adding latency.

There is a process called convolution which most audio people will be familiar with. If you want to make a latency free convolution effect, you can do it by dropping the first samples and dealing with some artifacts on device open. I personally think this is a horrible idea, but I could see some enterprising programmer somewhere going "I know!" and doing it. So even though I haven't seen it, I could believe in it happening for someone.

Holding the device open may be sufficient for Vista and later, but may not work for XP. Appending the zeros should, and has the added advantage of building in the waiting without much further work. This is something that can probably also be improved with #5096, so I'm mentioning that ticket here.

@challsworth2 is this still an issue?

@michaelDCurran your thoughts are very apprecaited, thanks.

@camlorn any updates on this?
@LeonarddeR I know you have created an issue which is somehow related, I had this issue as well. See #8017. @mltony created a wonderful add-on for solving this. In my case it works very reliable.

Closing in favor of #10185. And this might be fixed by #11024.