Re: speech-dispatcher audio output using gstreamer (idea)

[Janina Sajka <janina rednote net>]

If you're looking for another transport layer to supplant pulseaudio,
jackd is the top shelf application on Linux. It's designed for real time
professional audio production. The jack people care about things like 0
latency and 0 xruns.

Frankly, pulseaudio is a poor cousin to jackd, imho. Not sure why RH
felt the need to create that poor cousin, but there we are.

Jack's home page:

http://jackaudio.org

Janina

Luke Yelavich writes:
> On Thu, Nov 12, 2009 at 03:19:11AM EST, Rui Batista wrote:
> > Hi,
> > 
> > This could be my crazyest idea ever but I'd like to propose it and know
> > the pros and cons of it.
> > 
> > Since orca would enevitably switch to speech-dispatcher for it's speech
> > output and speech-dispatcher audio code, at least for pulseaudio, is a
> > bit bad, how about switching to gstreamer for outputing audio? I don't
> > know if gstreamer is suitable to such high real-time requirements but at
> > least most of the audio stuff is already done... And implementing some
> > king of recording speech and so one is trivial.
> > 
> > What do you all think? Sorry if it is stuppid...
> 
> Its not a stupid idea at all, however there are a coupel of reasons why its probably not worth exploring, at least from my point of view.
> 1. It introduces a lot more external dependencies to speech-dispatcher. Sure one doesn't have to build gstreamer support, however if a distro wants to satisfy two sets of users, those whowant a minimalist embedded system, and a desktop usage system with the one package, this makes things complicated, to the point where they would likely not build gstreamer support in the first place.
> 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, and the pulseaudio output code itself. Basically it comes down to dynamically re-adjusting buffers according to what pulseaudio says its doing for buffering. So I think its easier to fix code already written, then to write new output code from scratch, which may take time to get to the point where it runs as well as other output code.
> 
> I wouldn't be against someone writing a patch to support gstreamer, and I'd be happy to test it, however I don't think its a good use of time at this point. Such time in my opinion, is better spent helping with issues elsewhere in either speech-dispatcher, or Linux accessibility.
> 
> Luke
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

-- 

Janina Sajka,	Phone:	+1.202.595.7777;
		sip:janina CapitalAccessibility Com
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina a11y org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)