Re: [orca-list] orca and speech-dispatcher

[Michael Whapples <mwhapples aim com>]

I have created a patch for this and put it against a bug report 
http://bugzilla.gnome.org/show_bug.cgi?id=636824.

Michael Whapples
On 08/12/10 15:17, Michael Whapples wrote:
> Hello,
> In trying to find the cause of a problem I am having with orca, 
> speech-dispatcher and ibmtts, I discovered a potential problem with 
> orca's use of speech-dispatcher.
>
> The problem is that orca does not set any priority levels and relies 
> on the default priority level of speech-dispatcher. You may ask what 
> is the problem with this? Well there are possibly two issues:
> 1. It is possible for the user to change the default priority level in 
> speechd.conf which alters how each call to speak is handled and some 
> levels can actually lead to output which is not correct from orca (eg. 
> the text priority level would mean each call will stop the last speech 
> output and this means that where orca sends output in a few calls like 
> when there is a line with a link half way across a line in firefox, 
> you will only here the last call to speak).
> 2. This is related to the first, I suspect that the default for when 
> priority is not set in speechd.conf is not correct and if 
> speech-dispatcher developers feel this way and fix it then this will 
> lead to the priority level being text with the undesired impact as above.
>
> Now the question is how to resolve it. I see two ways:
> 1. When orca creates its speech-dispatcher client it could explicitly 
> set its priority level so making it unaffected by changes in 
> speech-dispatcher or speechd.conf. This should be very simple to do 
> and I could easily create a patch in minutes (I guess). If going down 
> this route what level would be suggested? I think from reading 
> speech-dispatcher documentation it would probably be message although 
> important seems to be the current default orca has been designed 
> around. Setting the level to message would allow only output with 
> priority important to interrupt orca and would maintain the current 
> behaviour that multiple outputs from orca would be queued rather than 
> the later ones interrupting the earlier ones. Speech-dispatcher 
> documentation indicates important should be used rarely as nothing can 
> interrupt it.
> 2. Orca could make greater use of the priority levels of 
> speech-dispatcher. This might be a better solution as it would mean 
> that its output would be considered in importance to other 
> applications producing speech output. The difficulty would be, is orca 
> designed in such a way that priorities could be set for each call of 
> speak? How much work would it be for this to be supported? I imagine 
> it might be quite a bit of work.
>
> Michael Whapples