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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Janina Sajka, Phone: +1.202.595.7777; sip:[email protected] 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 [email protected] Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C) _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
