On Fri, Nov 26, 2010 at 12:01:21PM -0600, Nolan Darilek wrote:
Hey folks. Man this is an infuriating bug. Sometimes I have to wait for upwards of a minute for Orca to process a long batch of links in continuous read. I can't believe this isn't bothering anyone else as much as it does me, but I lose so much of my day while Orca twiddles its virtual thumbs doing gods know what. And it's not like I can stop Orca from reading these links once it starts, as it seems like you can only stop speech if it's actually speaking, so I have to play a game of whack-a-mole and pound control as soon as speech starts in order to keep the long list of links from being trotted out. I know that we thought we had a solution at one point, then the OpenTTS/SD fork madness swallowed the change. I just have a hard time believing that this is where the investigation ends. Can we look through commits made to OpenTTS in mid-May and see if one may have changed something? Or can someone with more experience with such things than I, I dunno, profile this code or something? I know we don't know why this is happening, but it isn't as if there's no way to find out.
well, it looks like what ever the problem is its in orca somewhere. I
made a test page with 50 links in a row and had orca read it. Heres
some of the output of top while that was going on.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3964 tbsaunde 20 0 298m 29m 4172 S 56 1.5 18:54.71 python
4088 tbsaunde 20 0 559m 182m 16m R 51 9.2 22:28.61 firefox-bin
3626 tbsaunde 20 0 133m 4144 2264 S 6 0.2 1:36.60 at-spi-registry
24902 root 20 0 139m 4612 2748 S 3 0.2 0:50.60 sd_espeak
25672 tbsaunde 20 0 19064 1380 1000 R 1 0.1 0:00.05 top
22432 root 20 0 98.3m 1712 836 S 0 0.1 0:28.14 speech-dispatch
1 root 20 0 8352 656 540 S 0 0.0 0:01.36 init
From this the activity of speech dispatcher sd_espeak looks reasonable,
this is a highlevel look so it may well be missing something, but it
doesn't look like there is a problem there. On the other hand python
and firefox are burning up a lot of cycles, and at-spi-registryd is
using a bit more than I think it usually does. Since I have no
experience profiling python or other wise find hotspots in it someone
else with that knowledge will have to start looking at what's going on
here.
Trev
I'm sorry that all I can do is cheerlead, but my area is Android accessibility and high-level languages, not C and low-level stuff, so unless someone tells me how to get useful profiling information I'm not of much help. And I've got a lot to do contributing to that particular house of cards. But I find it hard to believe that we have to wait for a lightning bolt of inspiration to strike here. Has anyone profiled SD/Orca reading links continuously and figured out what's going on? Or is there a known solution in the pipeline? This message brought to you by my netbook, on which this bug is even *more* painful than it is on my dual-core desktop with 4G of RAM. Thanks. _______________________________________________ Speechd mailing list Speechd lists freebsoft org http://lists.freebsoft.org/mailman/listinfo/speechd
Attachment:
signature.asc
Description: Digital signature