I have solved my problem as follows; if there is any memory leak inside the
speech synthesizer it is isolated to the spawned task and is short lived and
outside of my app.
NSTask *ls = [[NSTask alloc] init];
NSString *thePhrase = [NSString stringWithFormat: @"\"%@\"",
phrase];
NSMutableArray *args = [NSMutableArray arrayWithCapacity: 20];
[args addObject: thePhrase];
[ls setLaunchPath: @"/usr/bin/say"];
[ls setArguments: args];
[ls launch];
[ls waitUntilExit];
[ls release];
Waiting until the task terminates is absolutely necessary to keep the app from
having more than one 'say' task going at the same time which totally garbles
the speech and hoses up the system. And the timing between spoken phrases is
perfect for my purpose.
On Aug 9, 2012, at 6:05 PM, Charlie Dickman wrote:
> I tried the Speech Synthesizer Manager too. It suffers from the same
> deficiency that NSSpeechSynthesizer does. I suspect that NSSpeechSynthesizer
> uses the Speech Synthesis Manager internally.
> On Aug 9, 2012, at 2:51 PM, Ken Thomases wrote:
>
>> On Aug 9, 2012, at 1:29 PM, Jens Alfke wrote:
>>
>>> On Aug 9, 2012, at 10:00 AM, Charlie Dickman <3tothe...@comcast.net> wrote:
>>>
>>>> NSTask *ls = [[NSTask alloc] init];
>>>> NSFileHandle *stdIn = [NSFileHandle
>>>> fileHandleForReadingAtPath: txtFilePath];
>>>> [ls setStandardInput: stdIn];
>>>> [ls setLaunchPath: @"/usr/bin/say"];
>>>> [ls launch];
>>>> [ls release];
>>>>
>>>> My problem is that the command speaks the text in the file when the task
>>>> is launched but not anything written to it subsequently.
>>>
>>> Yeah, when the NSFileHandle hits EOF on the file it will propagate the EOF
>>> to the task, which will then exit.
>>>
>>> What you want instead is to make your own NSStream that isn't tied to a
>>> file. But looking at the NSTask and NSFileHandle APIs, I don't see how you
>>> can attach an NSStream to a task...
>>
>> The correct thing to do is to use a pipe to send data to the task. You can
>> keep that open as long as you like and keeping writing new data. However,
>> you (Charlie) also wrote:
>>
>>> I have also looked into using an NSPipe but it doesn't seem to add anything.
>>
>> You want to look again because that should work. However, there's no reason
>> to believe that the "say" command will speak the data in dribs and drabs as
>> you write it. The man page says that, when input is not a TTY, the text is
>> spoken all at once. So, presumably it will not speak until you close the
>> pipe and it sees EOF and knows it has all of the data.
>>
>> If NSSpeechSynthesizer has problems, you might look into the Speech
>> Synthesis Manager. Either way, I would not expect that you could work
>> around the problems indefinitely using the "say" command, since it surely
>> uses those APIs under the hood. (The man page actually states that it uses
>> the Speech Synthesis Manager.)
>>
>> Regards,
>> Ken
>>
>
> Charlie Dickman
> 3tothe...@comcast.net
>
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/3tothe4th%40comcast.net
>
> This email sent to 3tothe...@comcast.net
Charlie Dickman
3tothe...@comcast.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
