reading the full screen

Frank Carmickle frank at
Thu Oct 25 13:43:54 EDT 2007

On Wed, Oct 24, Gregory Nowak wrote:
> Hash: SHA1
> Kirk,
> This happens with either hardware or software handshaking. Like I've
> said, both the fact that I haven't seen this behavior outside of a vm
> running in virtualbox, and that provox runs into the same sort of
> issue, I think this is a vbox-specific problem, and not a speakup
> one. I'll have to do some more testing to verify that, but I do think
> that vbox is to blame as of now at least.

More at issue here is most likely the scheduler.  I am sure that all of us know very well the trouble one can get in to when running audio on the same system that speakup is running on.  Just listen to an ogg file while listening to screen fulls of stuff.  The other way arround is also true.  If you use a softsynth like ttsynth, even with a small bit of code like spk-connect-ttsynth and you run a bunch of system tasks your synth gets interupted.  I do some silly tricks with renice to help this but it only goes so far.  The fact of the matter is that speakup is not scheduled like other tasks in the kernel.  It runs and when it is done it lets the rest of the system run.  This actually opens a large can o worms.  I suppose that one of the reasons why we like speakup so much is that we like that we can see the screen when we want to see the screen.  Meaning that speakup in a really nasty way preempts everything.  I have excepted this as it is for the time being.  My solution for it is to run speakup on one machine and log in to other machines from their.  Most of us these days are able to find old slow machines that people don't want any more and do this.  I do hope that some day speakup does become a kernel thread and then we can run it on all of our machines.


More information about the Speakup mailing list