Bug 467531

Thanks for the suggestion. I have a big update planned for after then F10 release and I'll get this in then.

If you don't mind, I'd really like to get this in before F10. We're shipping with PA on by default, and it would be a bit of a bummer to have non-working speech as a consequence of that.

I'm fine with that -- I just don't have time to work on it. 

Some notes:

This should go in /usr/share/festival/lib/init.scm rather than in /etc/festival/siteinit.scm since it's a system default rather than a local customization.

Are there any downsides to using this method?

Ok, I do the work to get this in the package, and I can put it into lib/init.scm.
I've asked Lennart for his opinion about the best way to make festival work with PA, I'll wait for his response before building this.

If festival behaves correctly we could simply run festival prefixed with "padsp".

> If festival behaves correctly we could simply run festival prefixed with
> "padsp".

Who is "we"? Any program which uses festival?

For F11, we should probably take a look at using speech-dispatcher with orca.

see http://live.gnome.org/Orca/SpeechDispatcher

Two thoughts:

1) should probably use paplay instead of aplay since it gives us the ability to name the stream in pavucontrol

2) isn't this a bad idea in general? I mean doesn't it mean festival will write out all audio to a file, and play the file adding lots of latency for orca users?

They use aplay? Oh my! That's horrible!

Does orca currently work at all when pulseaudio is running ?

As I said: longer-term, sound-dispatcher may be a better option. 
Or maybe just write a pa backend for festival.

Lennart, it doesn't use aplay right now, but Matthias's proposal in comment 0 was to use aplay.

Matthias, yea I was using orca the other day to test gnome bug 535827 and i was getting audio okay.

also interesting is the festival source tree seems to suggest it has a libesound backend, which should work with pa...

Actually, I can't reproduce the failure in comment 0.

Maybe it was broken for some reason and has since been fixed?

Can you still reproduce the original issue?

scratch comment 13.  i missed the "while playing music" bit.  i can reproduce if rhythmbox is playing music.

Anyone tried whether this would work?

(Parameter.set 'Audio_Command "pacat --channels=1 --rate=$SR $FILE")

so running

(Paramter.get 'Audio_Method)

yields, linux16audio instead of esdaudio

doing

(Parameter.set 'Audio_Method 'esdaudio)

then starting rhythmbox and playing music, followed by:

(SayText "hello")

gives the message "hello" on top of the music.

I think we just need to change the default audio backend to esdaudio.

Matthias pointed out this might break festival for runlevel 3 users.  

Lennart, do you know if it will?

To answer that question:

ESD: error writing - Bad file descriptor
#<Utterance 0xb7197818>

The thing with esd-style autospawning is that it is racy, does not do locking while testing whether to startup a new instance. I'd prefer if we didn't rely n esd style autospawning.

Which leaves us the options. a) use pacat or b) make sure that pulseaudio --start was rung and completed before festival becomes active.

pacat doesn't work if pulseaudio isn't running, right?

Yes, I think the only solution that has a chance of working in the absense of PA is aplay (which is why I put that in the initial comment, btw...)

Since pacat links against libpulse it would use the race-free PA-style autospawning. Hence using pacat is fine.

(In reply to comment #16)
> Anyone tried whether this would work?
> 
> (Parameter.set 'Audio_Command "pacat --channels=1 --rate=$SR $FILE")

So, on my rawhide system, this makes a horrible loud static noise. But this system has been constantly tracking rawhide for a year and a half or, and pulseaudio has always worked inconsistently.

It works on my system in X.  Haven't tried from runlevel 3.

okay i built festival with the pacat workaround for now.

We should revisit this at some point, though.