Text To Speech issues with Read Etexts Activity

[Hemant Goyal]

Hi,

I had written a mail to the speechd community regarding the problems that
James was facing some time back.

Hi,

James is using speech-dispatcher on the OLPC laptop. I would just like to
ask in the speechd community what is the exact meaning of the following
espeak.log messages. (I get similar log messages for each speech synthesis
request - either from spd-say or James' Read Etexts activity.


   1. Tue Jul  8 17:25:20 2008 [29778] ALSA: Setting access type to
   INTERLEAVED
   2.  Tue Jul  8 17:25:20 2008 [30690] ALSA: Setting sample format to
   S16_LE
   3.  Tue Jul  8 17:25:20 2008 [31120] ALSA: Setting sample rate to 22050
   4.  Tue Jul  8 17:25:20 2008 [31778] ALSA: Setting channel count to 1
   5.  Tue Jul  8 17:25:20 2008 [32067] ALSA: Setting hardware parameters on
   the ALSA device
   6.  Tue Jul  8 17:25:20 2008 [32968] ALSA: cannot set parameters (File
   descriptor in bad state) state=SUSPENDED

We cannot hear any audio output during speech-synthesis on the OLPC laptops.
Any hints about the problem will be greatly appreciated.

And this was the analysis by Hynek from the speechd community. (It would've
done well if I had cross posted the mail back then to devel..oh well)

1.
     Tue Jul  8 17:25:20 2008 [29778] ALSA: Setting access type to
     INTERLEAVED
 2.

      Tue Jul  8 17:25:20 2008 [30690] ALSA: Setting sample format to
     S16_LE
 3.

      Tue Jul  8 17:25:20 2008 [31120] ALSA: Setting sample rate to
     22050
 4.

      Tue Jul  8 17:25:20 2008 [31778] ALSA: Setting channel count to 1
 5.

      Tue Jul  8 17:25:20 2008 [32067] ALSA: Setting hardware
     parameters on the ALSA device
 6.

      Tue Jul  8 17:25:20 2008 [32968] ALSA: cannot set parameters
     (File descriptor in bad state) state=SUSPENDED


Hello,

on every request to play a sound, the ALSA device must
be initialized for the exact audio parameters (22050Hz,
1 channel signed 16 bit data, low endian...).

A call of the function snd_pcm_hw_params() is necessary
to set these parameters on the device and bring it
to the PREPARED state, where it is possible to play
audio. The only restriction given in the ALSA documentation
is that snd_pcm_hw_params() can't be called when ALSA
is in the state RUNNING. (But the documentation is  not really
complete.)

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g98ba19d2800b7d601277fd8c068505da

The last message (6) indicates that the call to snd_pcm_hw_params
fails. ,,File descriptor in bad state'' is the error message given
by alsa. The device is however well in the SUSPENDED state, which
contradicts this error message.

Since this essential step fails, the audio can't be played
and so you don't hear anything. Thus index marks are delivered
very fast etc. etc.

The exact code inside Speech Dispatcher audio library that
fails is:

MSG("Setting hardware parameters on the ALSA device");     if ((err =
snd_pcm_hw_params (id->alsa_pcm, id->alsa_hw_params)) < 0) {
  MSG("cannot set parameters (%s) state=%s",
      snd_strerror (err), snd_pcm_state_name(snd_pcm_
state(id->alsa_pcm)));     return -1;
  }

It looks to me that the error message is misleading and
the actual problem is elsewhere. Perhaps the audio device
in OLPC can't accept these parameters? Perhaps there
is some permission problem and it is not possible to bring
the audio into the PREPARED state? Perhaps this is a
one-channel soundcard and is being blocked by something
else?

I suggest to try whether 'aplay' works in the exact same
conditions (under the user that otherwise runs
speech-dispatcher) etc.

I did not get around to testing Hynek's suggestion till now however.

Best,
Hemant


On Tue, Jul 15, 2008 at 9:17 PM, Erik Garrison <erik at laptop.org> wrote:

> On Tue, Jul 15, 2008 at 09:06:02AM -0500, James Simmons wrote:
> > Michael,
> >
> > The activity logs contain no clues.  Really no message at all.
> >
> > The Activity window is present but non-responsive.  You can switch to
> > the main screen using F3 (the XO equivalent activity-switching key) but
> > you cannot shut down the application there.  When you switch back to
> > Read Etexts the screen is blank, as if something is preventing it from
> > repainting.  So the app doesn't bail out, it just hangs.  I can use
> > other activities like the log viewer and the terminal no problem.
> >
> > And of course nothing like this happens when testing with Xubuntu, or
> > when testing the standalone app containing the same code running under
> > the Terminal.
> >
>
> How would I obtain the source so that I can assist in debugging?
>
> Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080715/e52cd6c8/attachment.html>