espeak and pulseaudio

Tim Cross tcross at rapttech.com.au
Tue Apr 6 03:19:55 BST 2010


> On Mon, Apr 05, 2010 at 01:01:27PM EST, Tim Cross wrote:
>> I now plan to get speech-dispatcher running. I have a few questions which I'm
>> hoping others on this list can help clarify. 
>> 
>> 1. Given that ubuntu is moving to pulseAudio based configuration, why is
>> espeak and libespeak still being built against portaudio rather than
>> pulseaudio? Is this just to provide more flexibility an enable espeak to run
>> on both pulseaudio and non-pulseaudio based setups or are there other issues
>> with linking against pulseaudio that I'm unaware of and which might bite me
>> further down the track? As it seems there are issues when running espeak built
>> against portaudio under a pulseAudio configuraiton, is there justification for
>> having two different packages, one built against portaudio and one built
>> against pulse? 
> 
> Espeak is built against portaudio v19 because it allows the espeak command-line binary to be used without the need for pulseaudio. Yes I am aware that portaudio isn't helping, but its better than no espeak command-line binary working at all unless you run pulse.
> 
> Unfortunately its too late to address this for lucid, but I am seriously considering building two versions of espeak, one against portaudio, one against pulse, for lucid+1 and beyond. Ultimately I think espeak should move to a platform specific solution, i.e use the best liraries for individual platforms, but thats a lot more work.
>

OK, thats what I thought. I am quite surprised how much better espeak is
performing and how much better the speech is now I've re-built against
pulseAudio. I would agree that for pulseAudio based systems, a package linked
against pulseAudio and one linked against portAudio for non-pulse systems
would be the best way to go, though I can understand the additional work this
will require and the problems that brings. 
 
>> 2. I've seen some posts regarding patches to speech-dispatcher and other
>> related work and was wondering if I'm better off running with the ubuntu
>> Karmic packages, sources from the 'official' speech-dispatcher repository or
>> some other source? (I seem to remember seeing a reference to a separate
>> unofficial speech-dispatcher bzr repository on launchpad, but don't have a
>> specific URI).
> 
> If you are going to use lucid in the future, I suggest you use lucid's speech-dispatcher packages, as they have had a significant rework, in terms of pulseaudio output, and should work much better than the packages in karmic.

OK, I was going to upgrade to lucid as soon as it is released, so I'll go that
way. I want to be using a fairly recent SD version as I'd like to investigate
adding a SD module to emacspeak. I'm not sure how practicle this will be as
the emacspeak 'protocol' is somewhat ad hoc and I'm not sure how well it can
be mapped to what is required for SD. While I expect emacspeak's author will
be open to suggestions regarding mods etc, a complete change is unlikely. At
the moment, I'm working on another related project which I think will improve
the support emacspeak has for different TTS backends and as part of that
process, I'm trying to document the protocol. I hope to be in a better
position to evaluate an SD interface within the next couple of months.

>> 
>> 3. I've seen lots of reports of people having major issues with running
>> pulseAudio. While I found numerous issues with getting it to work well on my
>> system, it now seems to be working really well. Have I just been extremely
>> lucky or are all the reports maily the result of pulseAudio being a little
>> complex to get working well or are there real issues I'm not aware of? Are
>> there issues with using pulseAudio and speech-dispatcher?
> 
> Pulseaudio has really pushed the boundaries in the last few years, exposing many bugs both in audio drivers, and in the userspace library layer. A lot of people have experienced teething problems, which are largely sorted now, except for a few corner cases with less common hardware. You shoudln't have any problems now,unless you are using hardware that has weird behavior, i.e Creative sound hardware, or pro audio sound cards.
>

Just my luck, the three sound cards I have to work with are a Creative SB
Audigy 4, an Audigy SE and an Intel HDA. The Audigy SE and Intel HDA are on a
64 bit system. I've got them working well with pulse (I added the sound
developers PPA and am running the later pulse packages). The trickiest part
was getting the sample rates and formats correct for the Audigy SE and getting
everything to behave consistently re: two cards that would come up in
different orders after a boot. 

The Audigy 4 (running Debian rather than Ubuntu) is working well, but I had to
do a custom .asoundrc to get that working correctly. However, it is 32 bit and I'm
not running espeak on that system (using the IBM TTS). 

For future reference, is there a site or some other resource that gives some
indication of what sound cards are best or which drivers have the best support
etc. I've looked in the past, but never found anything. I did find some info
on Creative cards having problems with timer based scheduling etc, but I've
not experienced any problems of that type. Settig tsched to off, as suggested
in some docs, had no noticable impact. The most important change I made to
pulse was to set the sample rate to 48k and change the format to s32le rather
than s16le and ensuring pulse was running with high priority realtime
scheduling. Once that was done, all has worked really well and I'm quite
impressed with the functionality that pulse provides. 

thanks,

Tim



More information about the Ubuntu-accessibility mailing list