[raspberry-vi] New image - initial reports
- From: Mike Ray <mike@xxxxxxxxxxxxxxx>
- To: raspberry-vi@xxxxxxxxxxxxx
- Date: Mon, 14 Apr 2014 16:37:58 +0100
Hello list,
There are a couple of comments from one user about the new image.
Reading on you might be fooled into thinking the image is unusable but I
think it is a few hundred percent better than before and the audio is
now solid.
The major issue is about the keyboard responsiveness, and here are some
explanations and suggestions from me:
speech-dispatcher, which is the speech server we are now using on this
image because it gives us better quality audio than using 'espeakup' to
connect the screen-reader to the 'espeak' speech synthesiser, and
because we need speech-dispatcher to be running for Orca to ever work,
has some quirks about it.
Notable of these is the way sd queues text for synthesis, and then plays
back sampled audio after it has returned from the speech synthesiser.
The only audio module we are using currently is espeak, and the
configuration for the speech-dispatcher espeak module is in:
/etc/speech-dispatcher/modules/espeak.conf
This file has a couple of settings in it which we have been fiddling
with to get things working better. These are:
EspeakAudioChunkSize
and:
EspeakAudioQueueMaxSize
The original settings of these two values were:
EspeakAudioChunkSize 3000
EspeakAudioQueueMaxSize 441000
The first figure is in milliseconds. The second figure controls the
size of the queue that stores audio samples and espeak events.
These settings make the keyboard very unresponsive. This is because the
espeak module is threaded, which means it has several threads of
execution. Each thread has to be synchronized with the others to make
sure each does not try to use a resource which another has.
For example the speech synthesis thread cannot stuff samples into the
queue at the same time as the playback thread reading the samples and
removing them from the queue for playback.
Speech synthesis works by sending some text to espeak and setting a
callback function, which executes when the samples are ready. The
callback thread must then block while it waits for the playback thread
to unlock the queue. Like waiting at a red light.
The original settings for these two parameters in the espeak.conf file
seem to be fine for a desktop machine with plenty of poke, but for the
poor little Pi, it is a headache.
So we tried several settings. The image was published with these settings:
EspeakAudioChunkSize 512
EspeakAudioQueueMaxSize 2706
The queue size we are using is massively smaller than the default and
makes for a much smaller footprint for speech-dispatcher. Rill has
since commented that reducing it further to 2500 is even better. And I
have found this afternoon that I think increasing the
EspeakAudioChunkSize to 1024 makes it even better. So my settings are now:
EspeakAudioChunkSize 1024
EspeakAudioQueueMaxSize 2500
There is also some indication that making a change in:
/etc/speech-dispatcher/speechd.log, as follows:
Change LogLevel from 3 to 0 and reboot.
Speeds things up a bit too. This is probably because if SD is logging
much data then the slowness of SD card writes will slow it down.
A lot changes when you select a slower speaking rate. If a slower rate
is selected and saying a single character takes a significant fraction
of a second, things get even more sticky. Which suggests a slightly
higher number for EspeakAudioChunkSIze is better.
I am currently looking at whether reducing the espeak audio sampling
rate from 22050Hz to 11025Hz might speed things up as well.
And potentially a restructuring of the code in the speech-dispatcher
espeak module to take speech synthesis out of the main thread might
help. But this is a big job and even if I do that, the bottom line is
that two threads cannot access the queue at the same time, so there
still has to be thread synchronisation and at some point some function
call or other is going to have to block and hold up the rest.
Rather more worrying is that Rill has reported that the image
occasionally crashes. This may be a re-occurrence of the VCHIQ problem
we had before. I am not sure why speech-dispatcher does not stutter
where espeakup does, and I always thought the stuttering and the VCHIQ
crash were related to the same problem, but maybe not. Unfortunately the
VCHIQ code is not open source so I can't hack it.
I can still put back some of my espeak latency tweaks and see if they
help so all is not lost. And I will look into speech-dispatcher and see
if I can work out why it doesn't stutter because this might give us a
clue into why the VCHIQ crashes occur. If I can find a way of making
sure the pointer sent to the kernel by the VCHIQ process is never NULL,
like by pointing it at silence, that might stop the error.
Mike
-- Michael A. Ray Analyst/Programmer Witley, Surrey, South-east UK The
box said: 'install Windows XP, 7 or better'. So I installed Linux
Interested in accessibility on the Raspberry Pi? Visit:
http://www.raspberryvi.org/ From where you can join our mailing list for
visually-impaired Pi hackers
===========================================================
The raspberry-vi mailing list
Archives: //www.freelists.org/archives/raspberry-vi
Administrative contact: <mike.ray@xxxxxxxxxxxxxx>
-----------------------------------------------------------
Raspberry Pi and the Raspberry Pi logo are trademarks of the Raspberry Pi
Foundation.
This list is not affiliated to the Raspberry Pi Foundation and the views and
attitudes expressed by the subscribers to this list do not reflect those of the
Foundation.
Mike Ray, list creator, January 2013
Other related posts:
- » [raspberry-vi] New image - initial reports - Mike Ray
