Sorry was away from the computer this weekend.
I have implemented David's suggestion and made the speechlock part of
the code dependent on OSX version.
It is only executed if OSX version is less than 10.9.
I've checked this in to the e-mac-speak svn repo.
As I've only just made the changes it hasn't had much testing. Having
said that it certainly appears to help things here.
I haven't noticed the voicelock issues that Haden mentions as yet. They
may still be there though.
If people could report success or otherwise on both 10.9 and earlier
that would be appreciated.
David Tseng <email@example.com> writes:
> To reiterate...anyone doing serious work on a Mac should probably refrain
> from upgrading from 10.8 to 10.9 at least until 10.9.1.
> - David
> On Sun, Oct 27, 2013 at 10:54 AM, Haden Pike <firstname.lastname@example.org> wrote:
>> Commenting out everything from speechLock.acquire() to the final
>> speechLock.release() at the top of the processSpeechQueue() function
>> partially solves the problem. Emacspeak reads everything it should, but
>> the server still has some strange interactions with voice-lock. If
>> switching buffers fast, for instance, the server won’t say the name, of the
>> Nevertheless, I’ve got the most important functionality of Emacspeak back.
>> On Oct 27, 2013, at 1:16 PM, David Tseng <email@example.com> wrote:
>> While implementing the server a while ago, I discovered a ref counting bug
>> in the Mac tts implementation. If I recall correctly, end callbacks were
>> not getting sent properly as a result (i.e. end callbacks of the previous
>> utterance were sent *after* start callbacks of the current utterance). My
>> guess is that 10.9 has corrected the issue.
>> I've not upgraded to Mavericks since I use my Mac for production work, but
>> I can take a look next weekend on a machine with Mavericks. The fix will
>> likely change/remove the extra acquire/release on the lock controlling
>> access to the speech queue for Mavericks only since the bug obviously still
>> exists pre-Mavericks.
>> - David
>> On Sun, Oct 27, 2013 at 10:04 AM, Haden Pike <firstname.lastname@example.org> wrote:
>>> > > Maybe starting the application that is stored in environment variable
>>> DTK_PROGRAM is enough to run the server.
>>> > It is.
>>> > This may help in determining the cause of the problem.
>>> I tried that and these results might help diagnose the problem.
>>> I ran ./mac from the Emacspeak servers directory. After receiving the
>>> “Server ready” message, I typed the following:
>>> q this is a test
>>> q of the mac speech server.
>>> Typing d gave me “this is a test”. Typing d again gave me the second bit
>>> of queued text: “of the Mac speech server.
>>> Based on this, it looks like the speech queue is not being processed
>>> correctly. I don’t know the Cocoa technologies well, so am not sure where
>>> to start fixing this.
>>> To unsubscribe from the emacspeak list or change your address on the
>>> emacspeak list send mail to "email@example.com" with a
>>> subject of "unsubscribe" or "help".
If you have questions about this archive or had problems using it, please send mail to:firstname.lastname@example.org No Soliciting!
Emacspeak List Archive | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998
Emacspeak Files | Emacspeak Blog | Search the archive