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



The gnome dev scene is always giving a pulse. I think we all appreciate concientious input, Rui. I am not extremeley technical, but would love to see a forced-containership strategy be employed at the os level for all GUI elements. This would ultimately allow cascade rules for all visible objects and "pannability" for any window. This is crucial for low-vision users trapped in applications fixated on typical resolutions. Too often the window or dialog is clipped and visually inaccessible. Wholly unrelated, but the scene is alive. :)

On Nov 11, 2009, at 7:55 PM, Rui Batista <ruiandrebatista gmail com> wrote:

Hi,
Qui, 2009-11-12 às 08:03 +1100, Luke Yelavich escreveu:
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.

Maby you are right, I don't know how complicated it would be to get all
that dependencies configuration on the build system of
speech-dispatcher, it is already a bit hard to handle with all that
code... But is doable if needed I think

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 looked at the pulse output code, but is very complicated for me right
now, don't know very much about pulseaudio internals to understand all
that calls and buffer handling...

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.

You're right. I would right the gstreamer support if needed but if there
are other things more important I can also look at that. Besides
pulseaudio output is there anything you think it would be good to take a
llook at? 10.04 LTS is comming and I'd like to contribute a bit to the
OS I'm using all the time :)

regards,

Rui Batista
Luke
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
Rui Batista
E-mail/googletalk: ruiandrebatista (at) gmail (dot) com
MSN/WLM: ruiandrebatista (at) hotmail (dot) com (don't send mail to this
on)
Skype: ruiandrebatista
twitter: http://twitter.com/ragb
weblog: http://outputstream.wordpress.com

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list


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