When notably the audio card is busy, we should report the issue to the
application, but still permit the application to retry submitting text
to synth, and eventually succeed to open it.
This change simply fixes the update of the out_samplerate variable to track
whether audio is open, and if not when text is submitted by the application,
try again to open it.
Valgrind reports
==20307== Invalid write of size 1
==20307== at 0x4E856FE: Wavegen.part.1 (wavegen.c:880)
==20307== by 0x4E86682: Wavegen (wavegen.c:670)
==20307== by 0x4E86682: Wavegen2 (wavegen.c:1235)
==20307== by 0x4E86682: WavegenFill2 (wavegen.c:1317)
==20307== by 0x4E86CA7: WavegenFill (wavegen.c:1398)
==20307== by 0x4E7093F: Synthesize (speech.c:442)
==20307== by 0x4E712E0: sync_espeak_Synth (speech.c:549)
==20307== by 0x4E8A5C0: process_espeak_command (espeak_command.c:317)
==20307== by 0x4E8B387: say_thread (fifo.c:333)
==20307== by 0x50E85A9: start_thread (pthread_create.c:463)
==20307== by 0x53F5CBE: clone (clone.S:95)
==20307== Address 0xad5e1bd is 0 bytes after a block of size 2,205 alloc'd
==20307== at 0x4C2CABF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20307== by 0x4C2EE04: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20307== by 0x4E70CFC: espeak_ng_InitializeOutput (speech.c:286)
==20307== by 0x4E6176E: espeak_Initialize (espeak_api.c:67)
==20307== by 0x10A5D8: initialize_espeak (espeak.c:303)
==20307== by 0x109D1D: main (espeakup.c:201)
==20307==
Indeed, the out_ptr >= out_end test is not enough: it only checks that
one byte can fit the buffer, while klatt and wavegen produce two bytes.
This reverts commit d08b8e43ca.
This commit causes gcc-4.8 to output a different SHA1 hash on the
language-phonemes test for `af` (the first language tested). It
does not break on clang or on gcc-7 so may be a compiler bug,
however the Travis CI build server is using it on Ubuntu Trusty
(14.04 LTS) and so may other older OSes.
This is a fix for https://github.com/nvaccess/nvda/issues/7740.
With the addition of emoji support, dictionary entries can now be
longer than 128 bytes. This fix makes sure the character is
interpreted as an unsigned byte so it does not treat long entries
as having a negative offset.
Treating the offset as a signed byte (like in the previous code)
could cause the hash chain search to loop indefinitely when
processing certain input, like the Tamil characters in the NVDA
issue noted above that is added as a test case to translate.test.
Reece H. Dunn