Re: Speech Dispatcher and audio



Hello,
On Do, Nov 12, 2009 at 09:55:45 +0000, Hynek Hanke wrote:
> Luke Yelavich wrote:
> > 2. The pulseaudio problems are fixable, it just requires a bit of work to re-adjust the buffering metrics used in the speech synthesizer drivers
> 
> Hello Luke and all,
> 
> we did such experiments last year, and we communicated with Lennart,
> tested several patches, kernels etc. and though we got some improvements,
> they couldn't compare to ALSA in speed or reliability. There are some
> principal problems:
 
Have you tested speech-dispatcher espeak-generic?
espeak -stdout |paplay
It works reliable and realy with low latency with the karmic kernel.

A few weeks ago lennart wrote to the pulse mailinglist that the
xmms-pulse stuff shouldn't be used to create a driver for pulseaudio.
It was a dirty hack and isn't maintained.

What about integrating paplay's code to the speech-dispatcher pulse
output module?
It's smal and works reliable.

I am now using the sd_generic with espeak under gentoo and tested it on
the karmic live cd (with a11y profile).
Please try it.
BR.
halim



> 1) For this kind of architecture, where there are multiple
> processes in the audio chain, we need low latency
> and pre-emption in kernel as explained by Lennart
> and also documented in Jack. Distributions don't normally
> offer this to stay compatible with some proprietary drivers.
> 
> 2) Pulse Audio itself (not the backend) needed some serious work
> on analysing and fixing issues related to buffer metrics
> and the glitch-free model at that time, but the main developers
> were unwiling to devote significant time to the issues important
> for accessibility.
> 
> I don't know if something changed in these two points from then,
> but unless we are sure about it, it doesn't seem to be reasonable
> to spend more time on PulseAudio.
> 
> Since the problem is in the architecture or PulseAudio itself,
> I don't think experiments using Gstreamer on top of PA or using
> Jack instead of PA and such can help it.
> 
> Now we tend to think that any solution where the audio
> is not output to kernel space directly from the synthesis
> driver (like we do with ALSA) is not a possible way given
> the current state of things.
> 
> Of course you are welcome to cross check these results,
> that would be very useful. There might be something which
> changed or something that we are missing.
> 
> With regards,
> Hynek Hanke

-- 
Halim Sahin
E-Mail:				
halim.sahin (at) t-online.de



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]